ทำไมเราต้องมีโบรกเกอร์ข้อความอย่าง RabbitMQ บนฐานข้อมูลอย่าง PostgreSQL

ฉันใหม่เพื่อโบรกเกอร์ข้อความเช่นRabbitMQที่เราสามารถใช้ในการสร้างงาน / คิวข้อความสำหรับระบบการตั้งเวลาเช่นคื่นฉ่าย

ตอนนี้นี่คือคำถาม:

• ฉันสามารถสร้างตารางในPostgreSQLซึ่งสามารถผนวกเข้ากับงานใหม่และบริโภคโดยโปรแกรมผู้บริโภคเช่น Celery

• ทำไมบนโลกนี้ฉันต้องการตั้งค่าเทคโนโลยีใหม่ทั้งหมดสำหรับ RabbitMQ นี้

ตอนนี้ฉันเชื่อว่าการปรับสเกลไม่สามารถตอบได้เนื่องจากฐานข้อมูลของเราเช่น PostgreSQL สามารถทำงานในสภาพแวดล้อมแบบกระจาย

ฉัน googled สำหรับปัญหาใดที่ฐานข้อมูลโพสท่าสำหรับปัญหาเฉพาะและฉันพบ:

• การสำรวจความคิดเห็นทำให้ฐานข้อมูลไม่ว่างและมีประสิทธิภาพต่ำ
• การล็อคตาราง -> มีประสิทธิภาพต่ำอีกครั้ง
• งานหลายล้านแถว -> อีกครั้งการสำรวจมีประสิทธิภาพต่ำ

ทีนี้ RabbitMQ หรือนายหน้าข้อความอื่น ๆ แบบนั้นแก้ปัญหาเหล่านี้ได้อย่างไร

นอกจากนี้ฉันพบว่าAMQPโปรโตคอลเป็นสิ่งต่อไปนี้ มีอะไรที่ยอดเยี่ยมในเรื่องนี้?

สามารถRedisยังสามารถใช้เป็นโบรกเกอร์ข้อความหรือไม่? ฉันพบว่ามันคล้ายกับ Memcached มากกว่า RabbitMQ

กรุณาส่องไฟนี้!

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

สำหรับปัญหาที่คุณพูดถึง:

• การสำรวจความคิดเห็นรักษาฐานข้อมูลที่มีประสิทธิภาพและมีประสิทธิภาพต่ำ : การใช้ Rabbitmq ผู้ผลิตสามารถผลักดันการอัปเดตให้ผู้บริโภคซึ่งมีประสิทธิภาพมากกว่าการสำรวจ ข้อมูลจะถูกส่งไปยังผู้ใช้เมื่อจำเป็นต้องใช้โดยไม่จำเป็นต้องมีการตรวจสอบที่สิ้นเปลือง

• การล็อคตาราง -> มีประสิทธิภาพต่ำอีกครั้ง:ไม่มีตารางสำหรับล็อค: P

• งานหลายล้านแถว -> การสำรวจอีกครั้งมีประสิทธิภาพต่ำ:ดังที่ได้กล่าวไว้ข้างต้น Rabbitmq จะทำงานได้เร็วขึ้นเมื่ออยู่ใน RAM และให้การควบคุมการไหล หากจำเป็นก็สามารถใช้ดิสก์เพื่อเก็บข้อความชั่วคราวได้หาก RAM ไม่เพียงพอ หลังจาก 2.0, Rabbit ได้ปรับปรุงการใช้ RAM อย่างมีนัยสำคัญ ตัวเลือกการจัดกลุ่มนอกจากนี้ยังมี

เกี่ยวกับ AMQP ฉันจะบอกว่าคุณสมบัติที่ยอดเยี่ยมจริงๆคือ "การแลกเปลี่ยน" และความสามารถในการกำหนดเส้นทางไปยังการแลกเปลี่ยนอื่น ๆ สิ่งนี้จะช่วยให้คุณมีความยืดหยุ่นมากขึ้นและช่วยให้คุณสร้างประเภทของการกำหนดเส้นทางที่ซับซ้อนซึ่งมีประโยชน์มากเมื่อปรับขนาด สำหรับตัวอย่างที่ดีโปรดดู:

_{(แหล่งที่มา: springsource.com )}

และ: http://blog.springsource.org/2011/04/01/routing-topologies-for-performance-and-scalability-with-rabbitmq/

ในที่สุดเกี่ยวกับ redis ใช่มันสามารถใช้เป็นนายหน้าข้อความและสามารถทำได้ดี อย่างไรก็ตาม Rabbitmq มีคุณสมบัติการจัดคิวข้อความมากกว่า redis เนื่องจาก Rabbitmq ถูกสร้างขึ้นจากพื้นดินจนเป็นคิวข้อความเฉพาะระดับองค์กรที่มีคุณสมบัติครบถ้วน ในทางกลับกัน Redis ถูกสร้างขึ้นเป็นหลักเพื่อเป็นที่เก็บคีย์ - ค่าในหน่วยความจำ (แม้ว่ามันจะทำอะไรได้มากกว่านั้นในตอนนี้; มันยังเรียกว่ามีดกองทัพสวิส) ถึงกระนั้นฉันได้อ่าน / ฟังผู้คนจำนวนมากบรรลุผลลัพธ์ที่ดีด้วย Redis สำหรับโครงการขนาดเล็ก แต่ไม่เคยได้ยินเรื่องนี้ในแอปพลิเคชันขนาดใหญ่

นี่คือตัวอย่างของการใช้ Redis ในการติดตั้งแชทแบบโพลยาว: http://eflorenzano.com/blog/2011/02/16/technology-behind-convore/

PostgreSQL 9.5

PostgreSQL 9.5 SELECT ... FOR UPDATE ... SKIP LOCKEDประกอบด้วย การดำเนินการนี้จะทำให้การทำงานของระบบการเข้าคิวมากง่ายและง่าย คุณอาจไม่ต้องการระบบการจัดคิวภายนอกอีกต่อไปเพราะตอนนี้มันง่ายที่จะดึงแถว 'n' ที่ไม่มีเซสชั่นอื่นถูกล็อคและล็อคพวกเขาไว้จนกว่าคุณจะยืนยันว่างานเสร็จแล้ว มันยังทำงานร่วมกับธุรกรรมสองเฟสเมื่อเมื่อต้องการการประสานงานภายนอก

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

รุ่นเก่ากว่า

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

นั่นเป็นเหตุผลว่าทำไมเครื่องมืออย่างPGQ จึงมีอยู่

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

หากคุณไม่ต้องการการดึงคิวหลายคนพร้อมกันสูงการใช้ตารางคิวเดี่ยวใน PostgreSQL นั้นสมเหตุสมผลมาก