คิวข้อความ ฐานข้อมูลเทียบกับ MQ โดยเฉพาะ

ฉันหลังจากคำแนะนำเกี่ยวกับการจัดคิวข้อความ เรามีข้อกำหนดสำหรับ "งาน" ที่จะโพสต์ในคิวข้อความ

ข้อเสนอแนะดั้งเดิมคือเพียงใช้อินสแตนซ์ SQL Server และประมวลผลข้อความจากนั้น ทุกสิ่งที่ฉันได้อ่านบนอินเทอร์เน็ตแสดงให้เห็นว่าการใช้ฐานข้อมูลสำหรับ Message Queue ไม่ใช่วิธีที่ปรับขนาดได้ ด้วยเหตุนี้จึงแนะนำให้ใช้ความคิด RabbitMQ หรือบุคคลที่สามอื่น ๆ MQ

อีกสิ่งที่ควรคำนึงถึงก็คือข้อกำหนดสำหรับ "การประมวลผลงาน" จะไม่ต่ำกว่า 30 วินาทีดังนั้นกระบวนการที่ทำหน้าที่จะสำรวจฐานข้อมูลทุก ๆ 30 วินาที สำหรับฉันแล้วมันไม่ได้เลวร้ายนักและอาจใช้ได้ดีโดยไม่ต้องเพิ่มการโหลดจำนวนมากในฐานข้อมูล

เรามีฐานข้อมูลอยู่แล้วในลูกค้าของเราที่เราสามารถใช้สิ่งนี้ได้ดังนั้นมันจะไม่เพิ่มการสนับสนุนพิเศษที่จำเป็นสำหรับลูกค้าของเราในขณะที่ถ้าเราเพิ่ม MQ บุคคลที่สามจะมีการสนับสนุนพิเศษสำหรับการกำหนดค่าเครือข่าย ฯลฯ ซึ่งจะเป็น เป็นจำนวนมากเนื่องจากมีผู้ใช้จำนวนมาก

ตัวเลือกอื่นที่ฉันกำลังพิจารณาคือให้ผู้ใช้เลือกระหว่างกัน หากพวกเขาเป็นผู้ใช้รายเล็กโซลูชันของ SQL Server จะใช้ได้ แต่ถ้าพวกเขาเป็นผู้ใช้ที่มีขนาดใหญ่ขึ้นเราอนุญาตให้พวกเขากำหนดค่าโซลูชัน MQ ของบุคคลที่สาม

ฉันไม่ได้ขายในการแก้ปัญหาใด ๆ ฉันสงสัยว่าใครมีอะไรที่ฉันควรพิจารณาหรือคำแนะนำ

ทุกสิ่งที่ฉันได้อ่านบนอินเทอร์เน็ตแสดงให้เห็นว่าการใช้ฐานข้อมูลสำหรับ Message Queue ไม่ใช่วิธีที่ปรับขนาดได้

ความจริงที่ถูกละเลยบ่อยครั้งโดย " ไม่ใช้Xเพราะมันไม่ขยายขนาด " (ลิงก์มีภาษาที่บางคนอาจพบว่าไม่เหมาะสม) ฝูงชนก็คือสเกลนั้นไม่สำคัญเสมอไป ฉันจะบอกว่าถ้าคุณดูการใช้งานทุกรูปแบบบนพื้นผิวโลกโดยรวมมาตราส่วนก็ไม่ค่อยมีความสำคัญ

ความคิดเห็นของคุณอ้างอิงอัตรา 20,000 ข้อความต่อวันซึ่งหมายความว่าคุณกำลังมองหาที่ต้องการสนับสนุนอัตราเฉลี่ย 0.23 ข้อความต่อวินาที (หนึ่งทุก ๆ 4.3 วินาที) หากโครงการของคุณกลายเป็นคำสั่งซื้อสองขนาดที่ประสบความสำเร็จมากกว่าที่คุณคาดไว้ความต้องการของคุณข้ามไปที่การประมวลผล 23 ข้อความต่อวินาทีซึ่งเป็นงานที่ฉันยินดีมอบให้กับโทรศัพท์มือถืออายุสี่ขวบหรือราสเบอร์รี่ Pi นี่ยังไม่ใช่แอปพลิเคชั่นระดับสูงแม้ว่าคุณจะเปลี่ยนคำสั่งให้มีขนาดใหญ่ขึ้นอีก

ฉันได้ดู (โชคดีจากข้างสนาม) โครงการจบลงอย่างไม่ดีเพราะพวกเขาใช้เวลามากเกินไปที่จะคิดมากเกินขนาดเร็วเกินไปที่จะไม่เกิดขึ้นหรือไม่มีเวลาเลยเลยและถูกบดขยี้ในที่สุด เหมือนทุกสิ่งทุกอย่างมีสื่อความสุข หากคุณคิดว่าการปรับขนาดใหญ่สำหรับงานของคุณเป็นไปได้จริงก็ไม่ควรจะเป็นเรื่องยากที่จะทำให้กรณีธุรกิจสำหรับการทำจำนวนเล็ก ๆ ของการทำงานพิเศษที่จะสร้างในสิ่งที่เป็นนามธรรมมากพอส่วนรอบที่ไม่สามารถปรับขนาดได้ที่มีราคาไม่แพงในการปรับใช้ในขณะนี้ การทำเช่นนี้หมายความว่าในภายหลังหากความต้องการเครื่องชั่งเพิ่มขึ้นคุณมีวิธี (และอาจเป็นรายได้) ในการเปลี่ยนชิ้นส่วนเหล่านั้นโดยไม่ต้องคิดใหม่ทั้งระบบ

ในขณะที่ปริมาณข้อความของแอปพลิเคชันของคุณจะไม่สร้างฐานข้อมูลหรือระบบการจัดคิวข้อความทำให้เหงื่อออกแม้ในฮาร์ดแวร์ที่มีขนาดเล็ก แต่คุณอาจมีข้อกำหนดอื่น ๆ สำหรับวิธีการจัดการธุรกรรมข้อความของคุณ ข้อกำหนดเหล่านั้นคือสิ่งที่คุณควรประเมิน

คิวข้อความเข้ามาในตัวเองจริงๆเมื่อคุณมีหลายคนและจัดเส้นทางข้อความระหว่างพวกเขา fanout ไปยังผู้บริโภคมากกว่าหนึ่งคนเป็นต้น

ถ้าคุณมี 'คิวงาน' ของสิ่งที่คุณต้องการประมวลผล 'ออฟไลน์' ตาราง SQL จะทำได้ดี

อย่าลืมตรวจสอบให้แน่ใจว่าคุณมีวิธีการทำเครื่องหมายงานที่กำลังดำเนินการทำความสะอาดงานเก่าและแจ้งเตือนเมื่อระบบหยุด แต่สำหรับคิวเดียวที่จัดการสิ่งเหล่านี้ด้วยตนเองจะทำงานได้น้อยกว่าการบำรุงรักษาโซลูชันการจัดคิวแยกต่างหาก

ตามที่คนอื่น ๆ ได้กล่าวถึงสเกลอาจไม่สำคัญที่นี่ ปัญหาเกี่ยวกับการใช้กลไกการจัดเก็บสองแบบที่แตกต่างกันคือการทำธุรกรรมเชิงบูรณาการ

หากใช้คิวข้อความเฉพาะคุณต้องเลือกข้อใดข้อหนึ่งต่อไปนี้ในกรณีที่เกิดข้อผิดพลาด

1. อนุญาตให้ข้อมูลสามารถเป็น mb ได้ แต่ไม่ใช่ใน db
2. อนุญาตให้ข้อมูลสามารถอยู่ใน db แต่ไม่ได้อยู่ใน mb
3. การติดตั้งสองเฟสกระทำหรือกระจายธุรกรรมระหว่าง db an mq ซึ่งอาจมีความซับซ้อน

ปัญหาทั้งหมดเหล่านี้หายไปถ้าคุณบันทึกข้อมูลไว้ในที่เดียวโดยใช้ธุรกรรมปกติ ด้วยเหตุนี้การใช้ db เป็นคิวงานจึงเป็นคำตอบที่ดีมาก

สำหรับการปฏิบัติจริงเหตุผลหลักที่ฉันจะใช้คิวข้อความคือ:

• ฉันไม่จำเป็นต้องบูรณาการล้อ การออกแบบแม้แต่คิวข้อความที่ง่ายที่สุดโดยใช้ฐานข้อมูลต้องใช้เวลาคิดอย่างน้อยสองสามชั่วโมงการเข้ารหัสสองสามชั่วโมงเป็นต้น เปรียบเทียบกับการนำคิวข้อความไปใช้เวลาที่ต้องใช้ในการกำหนดค่าและ / หรือการกำหนดค่าแบบอัตโนมัตินั้นเป็นเรื่องเล็กน้อย
• คิวข้อความมีส่วนต่อประสานที่ดีและชัดเจนสำหรับผู้ผลิตและผู้บริโภค นี่อาจเป็นสิ่งสำคัญที่สุดในการเขียนใบสมัคร หากไม่มีส่วนต่อประสานคิวข้อความนั้นเป็นเพียงการรวบรวมข้อมูล
• คิวข้อความให้คุณสมบัติเพิ่มเติมที่อาจจำเป็นในอนาคต

เกี่ยวกับการอนุญาตให้ผู้ใช้เลือกนั่นเป็นรายละเอียดการใช้งานจริง ๆ ที่ผู้ใช้ไม่ควรสนใจ ผู้ใช้ควรได้รับอินเทอร์เฟซเดียวกันและไม่ควรมีความแตกต่างกับผู้ใช้หากใช้ฐานข้อมูลหรือคิวข้อความ เมื่อตั้งค่าการออกแบบเดียวตัวเลือกที่น่าจะเป็นสำหรับผู้ใช้คือจำนวนโหนดที่ต้องปรับใช้เพื่อรองรับความต้องการของพวกเขา

ฉันได้สร้างโซลูชันคิวข้อความ Mssql ซึ่งสามารถจัดการการดำเนินงาน 20k ต่อวินาทีตามการทดสอบประสิทธิภาพและเราต้องการเวลา 10 / วินาทีส่วนใหญ่ ฉันคิดว่าความจริงที่ว่าคุณสามารถมีความสำคัญในตัวเป็นคุณสมบัติที่คิวข้อความเฉพาะขาด และนี่เป็นข้อกำหนดที่สำคัญในกรณีของฉัน