เมื่อใดจึงควรใช้โปรโตคอลการจัดคิวข้อความขั้นสูงเช่น RabbitMQ [ปิด]

ใครสามารถอธิบายฉันในกรณีการใช้งานที่ฉันควรพิจารณาใช้ AMQP เช่น RabbitMQ ข้อดีและข้อเสียคืออะไร?

design message-queue

มีคำตอบที่ดีสำหรับคำถามที่คล้ายกันใน Stack Overflow: การใช้ JMS / message que จริงหรือไม่?

— กาน

คุณสามารถดูลิงค์ร้อง มันมีคำอธิบายกว้าง ๆ : stackoverflow.com/a/51377756/3073945

— Md. Sajedul Karim

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

หากคุณวางคิวระหว่างบริการบนเว็บและระบบบัญชีคุณจะสามารถ:

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

แน่นอนว่าคุณอาจมีสถานการณ์ที่ซับซ้อนมากขึ้นซึ่งจำนวนแอปพลิเคชันของคุณใหญ่กว่าสองและคุณต้องจัดการการสื่อสารระหว่างพวกเขา

— ВиталийОлегович
แหล่งที่มา

1) A คู่กับ B ดีกว่า A คู่กับ C และ C คู่กับ B อย่างไร

— ชาร์ลี

2) ทำไมไม่ใส่คิวเข้าไปในระบบบัญชี? ทำไมถึงแนะนำชิ้นส่วนกล่องดำเคลื่อนไหวใหม่ที่ต้องการการกำหนดค่าเพิ่มเติม

— ชาร์ลี

@ Charlie เกี่ยวกับคำถามที่ 1 ฉันได้แก้ไขคำตอบของฉันแล้ว เกี่ยวกับคำถามที่ 2 คุณหมายถึงอะไรโดยการใส่คิวเข้าสู่ระบบบัญชี คุณต้องการใช้โครงสร้างข้อมูลคิวหรือไม่? ในกรณีนี้คุณจะมีรหัสเพิ่มเติมที่จะเขียนเพื่อคงอยู่ คุณต้องการจำลองคิวโดยใช้ตารางฐานข้อมูลหรือไม่? คุณจะต้องเขียนโค้ดที่ดีเพื่อจัดการตารางอีกครั้ง มีอะไรอีกบ้างที่ฉันไม่ได้คิด

— ВиталийОлегович

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

— Charlie

@ Charlie สันนิษฐานว่านายหน้าข้อความเดียวจะใช้ในหลายระบบ หรือจะมีพร็อกซี่เดียวสำหรับนายหน้า (ในกรณีของเราเรากำลังใช้อุปกรณ์ส่งข้อความตัวเดียวที่สามารถรองรับข้อความนับล้านต่อวินาทีสำหรับระบบทั้งหมดของเรา) สิ่งนี้สร้าง decoupling ที่มากขึ้นเพราะข้อความถูกสร้างขึ้นโดยระบบเดียวและระบบที่สนใจสามารถรับข้อความนั้นและดำเนินการตามตรรกะที่เหมาะสม ข้อต่อเดียวคือเข้าคิว

— Michael Brown

นอกเหนือจากการจัดเตรียมบัฟเฟอร์ระหว่างเว็บเซอร์วิสและเซอร์วิสแบ็คเอนด์อื่นคิวข้อความสามารถใช้สำหรับสถานการณ์ขั้นสูงเพิ่มเติมได้ Rabbit MQ (และผลิตภัณฑ์คิวข้อความสำหรับผู้ใหญ่อื่น ๆ หรือที่เรียกว่า MOM - Message Oriented Middleware) สามารถกำหนดเส้นทางและกระจายข้อความตามกฎที่แตกต่างกัน

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

นอกจากนี้เนื่องจาก MOMs ส่วนใหญ่มี sdks สำหรับหลายภาษาและแพลตฟอร์มพวกเขาสามารถใช้เพื่อรวมแอปพลิเคชันที่เขียนบนแพลตฟอร์มที่แตกต่างกัน

นี่เป็นเพียงบางสถานการณ์ที่ MOM เปิดใช้งาน

— Michael Brown
แหล่งที่มา