มีเหตุผลใดที่จะใช้ RabbitMQ กับ Kafka?

ฉันถูกขอให้ประเมิน RabbitMQ แทน Kafka แต่พบว่ามันยากที่จะหาเหตุผลที่ทำให้สิ่งที่ดีกว่า Kafka มีใครรู้บ้างไหมว่ามันจะดีกว่าในเรื่องของปริมาณงานความคงทนความหน่วงหรือความง่ายในการใช้งานหรือไม่?

RabbitMQ เป็นนายหน้าข้อความที่มั่นคงทั่วไปที่รองรับโปรโตคอลหลายอย่างเช่น AMQP, MQTT, STOMP และอื่น ๆ มันสามารถรองรับปริมาณงานสูง กรณีการใช้งานทั่วไปสำหรับ RabbitMQ คือการจัดการงานพื้นหลังหรืองานที่ต้องใช้เวลานานเช่นการสแกนไฟล์การปรับขนาดภาพหรือการแปลง PDF RabbitMQ ยังใช้ระหว่างไมโครไซต์ซึ่งทำหน้าที่เป็นวิธีการสื่อสารระหว่างแอปพลิเคชันหลีกเลี่ยงปัญหาคอขวดผ่านข้อความ

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

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

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

คิวของ RabbitMQ นั้นเร็วที่สุดเมื่อมันว่างเปล่าในขณะที่ Kafka เก็บข้อมูลจำนวนมากโดยมีค่าใช้จ่ายน้อยมาก - Kafka ถูกออกแบบมาสำหรับการถือครองและกระจายข้อความจำนวนมาก (ถ้าคุณวางแผนที่จะมีคิวที่ยาวมากใน RabbitMQ คุณสามารถดูคิวที่ขี้เกียจ )

คาฟคานั้นถูกสร้างขึ้นจากพื้นดินโดยคำนึงถึงการเพิ่มขนาดในแนวนอนโดยเพิ่มเครื่องเพิ่มเติมในขณะที่ RabbitMQ ได้รับการออกแบบมาสำหรับการปรับขนาดแนวตั้ง

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

อ่านเพิ่มเติมและข้อมูลการเปรียบเทียบสามารถดูได้ที่นี่: https://www.cloudamqp.com/blog/2019-12-12-when-to-use-rabbitmq-or-apache-kafka.html HTML

แนะนำอุตสาหกรรมกระดาษด้วย: "Kafka กับ RabbitMQ: การศึกษาเปรียบเทียบการอ้างอิงอุตสาหกรรม / การใช้งานการสมัครสมาชิกสองคน": http://dl.acm.org/citation.cfm?id=3093908

ฉันทำงานที่ บริษัท ที่ให้บริการ Apache Kafka และ RabbitMQ เป็นบริการ

ฉันได้ยินคำถามนี้ทุกสัปดาห์ ... ในขณะที่ RabbitMQ (เช่น IBM MQ หรือ JMS หรือโซลูชั่นการส่งข้อความทั่วไป) ใช้สำหรับการส่งข้อความแบบดั้งเดิม Apache Kafka ใช้เป็นแพลตฟอร์มสตรีมมิ่ง (การส่งข้อความ + การจัดเก็บข้อมูลแบบกระจาย + การประมวลผลข้อมูล) ทั้งสองถูกสร้างขึ้นสำหรับกรณีการใช้งานที่แตกต่างกัน

คุณสามารถใช้ Kafka สำหรับ "การส่งข้อความดั้งเดิม" แต่ไม่สามารถใช้ MQ สำหรับสถานการณ์เฉพาะของ Kafka

บทความ“ Apache Kafka vs. Enterprise Service Bus (ESB) - เพื่อนศัตรูหรือ Frenemies หรือไม่? ( https://www.confluent.io/blog/apache-kafka-vs-enterprise-service-bus-esb-friends-enemies-or-frenemies/ ) กล่าวถึงสาเหตุที่คาฟก้าไม่สามารถแข่งขันได้ แต่เสริมการบูรณาการและการแก้ปัญหาการส่งข้อความ (รวมถึง RabbitMQ) และวิธีการรวมเข้าด้วยกัน

5 ความแตกต่างที่สำคัญระหว่าง Kafka และ RabbitMQ ลูกค้าที่ใช้พวกเขา:

ระบบการส่งข้อความใดที่จะเลือกหรือเราควรเปลี่ยนระบบการส่งข้อความที่มีอยู่ของเรา?

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

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

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

ในอีกทางหนึ่งApache Kafkaไม่ใช่เพียงนายหน้าข้อความ LinkedIn ได้รับการออกแบบและนำมาใช้ครั้งแรกเพื่อใช้เป็นคิวข้อความ ตั้งแต่ปี 2011 คาฟก้าได้รับการเปิดแหล่งที่มาและพัฒนาอย่างรวดเร็วในแพลตฟอร์มสตรีมมิ่งแบบกระจายซึ่งใช้สำหรับการดำเนินการตามท่อข้อมูลเรียลไทม์และแอพพลิเคชั่นสตรีมมิ่ง

สามารถปรับขนาดในแนวนอนทนต่อข้อผิดพลาดชั่วร้ายเร็วและทำงานในการผลิตในหลายพัน บริษัท

องค์กรสมัยใหม่มีท่อส่งข้อมูลที่หลากหลายซึ่งเอื้อต่อการสื่อสารระหว่างระบบหรือบริการ สิ่งต่าง ๆ มีความซับซ้อนเพิ่มขึ้นเล็กน้อยเมื่อจำนวนบริการที่เหมาะสมต้องสื่อสารกันในเวลาจริง

สถาปัตยกรรมมีความซับซ้อนเนื่องจากต้องมีการผนวกรวมที่หลากหลายเพื่อเปิดใช้งานการสื่อสารระหว่างกันของบริการเหล่านี้ แม่นยำยิ่งขึ้นสำหรับสถาปัตยกรรมที่ครอบคลุมบริการ m source และบริการเป้าหมาย n การผสานรวมที่แตกต่างกัน nxm จำเป็นต้องถูกเขียน นอกจากนี้การรวมทุกครั้งจะมีข้อกำหนดที่แตกต่างกันซึ่งหมายความว่าอาจต้องใช้โปรโตคอลที่แตกต่างกัน (HTTP, TCP, JDBC ฯลฯ ) หรือการแสดงข้อมูลที่แตกต่าง (Binary, Apache Avro, JSON ฯลฯ ) ทำให้สิ่งต่าง ๆ มีความท้าทายมากยิ่งขึ้น . นอกจากนี้บริการต้นทางอาจแก้ไขภาระที่เพิ่มขึ้นจากการเชื่อมต่อที่อาจส่งผลกระทบต่อความหน่วงแฝง

Apache Kafka นำไปสู่สถาปัตยกรรมที่ง่ายและจัดการได้มากขึ้นโดยการแยกการส่งไปป์ไลน์ข้อมูล Kafka ทำหน้าที่เป็นระบบกระจายความเร็วสูงซึ่งบริการต้นทางผลักดันกระแสข้อมูลทำให้มีบริการเป้าหมายเพื่อดึงข้อมูลตามเวลาจริง

นอกจากนี้ยังมีอินเทอร์เฟซผู้ใช้โอเพ่นซอร์สและระดับองค์กรจำนวนมากสำหรับการจัดการ Kafka Clusters อยู่ในขณะนี้ สำหรับรายละเอียดเพิ่มเติมโปรดดูที่บทความของฉันภาพรวมของเครื่องมือตรวจสอบ UI สำหรับกลุ่ม Apache Kafkaและเพราะเหตุใด Apache Kafka

การตัดสินใจว่าจะไป RabbitMQ หรือ Kafka นั้นขึ้นอยู่กับข้อกำหนดของโครงการของคุณ โดยทั่วไปหากคุณต้องการนายหน้าข้อความ pub-sub แบบง่าย ๆ ให้ไปที่ RabbitMQ หากคุณต้องการสร้างสถาปัตยกรรมที่ขับเคลื่อนด้วยเหตุการณ์ที่องค์กรของคุณจะทำหน้าที่ในเหตุการณ์แบบเรียลไทม์ให้ไปที่ Apache Kafka เนื่องจากมีฟังก์ชั่นเพิ่มเติมสำหรับสถาปัตยกรรมประเภทนี้ (เช่น Kafka Streams หรือ ksqlDB)

ฉันรู้ว่ามันช้าไปหน่อยและบางทีคุณอาจพูดไปทางอ้อมแล้ว แต่อีกครั้งคาฟคาไม่ได้อยู่ในคิวเลยมันเป็นท่อนไม้

เพื่อให้ง่ายกรณีการใช้งานที่ชัดเจนที่สุดเมื่อคุณต้องการ RabbitMQ (หรือเทคโนคิว) มากกว่า Kafka คือสิ่งต่อไปนี้:

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

สิ่งที่คุณสามารถทำได้มากที่สุดคือทำในฐานะคนพวกนั้นและพยายามที่จะเปลี่ยนคาฟคาให้เป็นคิว: https://github.com/softwaremill/kmq

Yannick

ใช้ RabbitMQ เมื่อ:

• คุณไม่ต้องจัดการกับ Bigdata และคุณต้องการ UI ในตัวที่สะดวกสำหรับการตรวจสอบ
• ไม่จำเป็นต้องรอคิวที่จำลองได้โดยอัตโนมัติ
• ไม่มีผู้ใช้หลายรายสำหรับข้อความ - เนื่องจากต่างจาก Kafka ซึ่งเป็นบันทึก RabbitMQ เป็นคิวและข้อความจะถูกลบเมื่อใช้งานและได้รับการตอบรับ
• หากคุณมีข้อกำหนดที่จะใช้ Wildcards และ regex สำหรับข้อความ
• หากการกำหนดลำดับความสำคัญของข้อความเป็นสิ่งสำคัญ

ในระยะสั้น: RabbitMQ นั้นดีสำหรับกรณีการใช้งานง่ายโดยมีปริมาณการใช้ข้อมูลน้อยและมีข้อดีของคิวลำดับความสำคัญและตัวเลือกการกำหนดเส้นทางที่ยืดหยุ่น สำหรับข้อมูลขนาดใหญ่และปริมาณงานสูงใช้ Kafka

ฉันจะให้คำตอบอย่างมีวัตถุประสงค์บนพื้นฐานของประสบการณ์ของฉันกับทั้งสองฉันจะข้ามทฤษฎีที่อยู่เบื้องหลังพวกเขาโดยสมมติว่าคุณรู้แล้วและ / หรือคำตอบอื่น ๆ ที่ให้ไว้เพียงพอแล้ว

RabbitMQ : ฉันเลือกสิ่งนี้หากความต้องการของฉันนั้นง่ายพอที่จะจัดการกับการสื่อสารของระบบผ่านช่องทาง / คิวการเก็บรักษาและการสตรีมมิงไม่ใช่ข้อกำหนด เช่นเมื่อระบบการผลิตสร้างสินทรัพย์จะแจ้งให้ระบบข้อตกลงเพื่อกำหนดค่าสัญญาและอื่น ๆ

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

ประโยชน์อย่างเดียวที่ฉันคิดได้คือคุณสมบัติการทำธุรกรรมส่วนที่เหลือทั้งหมดสามารถทำได้โดยใช้คาฟคา

การไต่ระดับทั้งสองนั้นทำได้ยากในทางที่ทนต่อความผิดพลาดแบบกระจาย แต่ฉันต้องการทำให้เป็นกรณีที่ RabbitMQ มีขนาดใหญ่ขึ้น มันไม่ง่ายเลยที่จะเข้าใจ Shovel, Federation, คิวมิงค์ข่าวสารเกี่ยวกับกระจก, ACK, Mem, Fault tollerance เป็นต้นไม่ว่าคุณจะไม่มีปัญหาเฉพาะกับ Zookeeper ฯลฯ ใน Kafka แต่มีส่วนที่เคลื่อนไหวน้อยกว่าในการจัดการ ที่กล่าวว่าคุณได้รับการแลกเปลี่ยนหลายภาษากับ RMQ ซึ่งคุณไม่ได้ทำกับคาฟคา หากคุณต้องการสตรีมให้ใช้ Kafka หากคุณต้องการ IoT แบบง่ายหรือการส่งแพ็กเก็ตปริมาณสูงที่คล้ายกันให้ใช้ Kafka มันเกี่ยวกับผู้บริโภคที่ฉลาด หากคุณต้องการความยืดหยุ่นของ msg และความน่าเชื่อถือที่สูงขึ้นด้วยค่าใช้จ่ายที่สูงขึ้นและความซับซ้อนที่อาจเกิดขึ้นให้ใช้ RMQ

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

Apache Kafka เป็นตัวเลือกยอดนิยมสำหรับการเปิดใช้งาน data pipelines Apache kafka เพิ่ม kafka stream เพื่อรองรับการใช้งาน etl ที่เป็นที่นิยม KSQL ทำให้การแปลงข้อมูลภายในท่อเป็นเรื่องง่ายพร้อมที่จะส่งข้อความไปยังระบบอื่น KSQL เป็นเครื่องมือ SQL สตรีมมิ่งสำหรับ Apache Kafka มันมีอินเตอร์เฟส SQL แบบอินเทอร์เฟซที่ใช้งานง่าย แต่ทรงพลังสำหรับการประมวลผลสตรีมบน Kafka โดยไม่จำเป็นต้องเขียนโค้ดในภาษาการเขียนโปรแกรมเช่น Java หรือ Python KSQL สามารถปรับขนาดได้ยืดหยุ่นยืดหยุ่นผิดพลาดและเรียลไทม์ สนับสนุนการดำเนินการสตรีมมิ่งที่หลากหลายรวมถึงการกรองข้อมูลการแปลงการรวมการรวมการสร้างหน้าต่างและการทำให้เป็นเซสชัน

https://docs.confluent.io/current/ksql/docs/index.html

Rabbitmq ไม่ใช่ตัวเลือกยอดนิยมสำหรับระบบ etl สำหรับระบบที่ต้องการระบบรับส่งข้อความอย่างง่ายที่ให้ปริมาณงานน้อย

ฉันรู้ว่านี่เป็นคำถามเก่า แต่สถานการณ์หนึ่งที่ RabbitMQ อาจเป็นทางเลือกที่ดีกว่าคือเมื่อต้องรับมือกับการทำข้อมูลซ้ำ

ด้วย RabbitMQ โดยค่าเริ่มต้นเมื่อข้อความหมดแล้วข้อความนั้นจะถูกลบ ด้วยค่าเริ่มต้นของ Kafka ข้อความจะถูกเก็บไว้เป็นเวลาหนึ่งสัปดาห์ เป็นเรื่องปกติที่จะตั้งค่านี้เป็นเวลานานกว่าเดิมหรือแม้แต่จะไม่ลบทิ้ง

ในขณะที่ผลิตภัณฑ์ทั้งสองสามารถกำหนดค่าให้เก็บรักษาข้อความ (หรือไม่เก็บ) หากการปฏิบัติตาม CCPA หรือ GDPR เป็นเรื่องที่น่ากังวลฉันจะใช้ RabbitMQ

คาฟคานั้นดีกว่า RabbitMQ ในแง่ของปริมาณงานความทนทานความล่าช้า หากคุณคาดหวังการทำธุรกรรมน้อยกว่า 10k / วินาทีคุณสามารถใช้ RabbitMQ ได้ แต่ขึ้นอยู่กับการใช้งานของคุณ

ฉันใช้ Kafka ในผลิตภัณฑ์ของเราซึ่งเราจัดการธุรกรรมมากกว่า 70k / วินาทีและเวลาในการตอบสนองโดยเฉลี่ยอยู่ที่ 15 มิลลิวินาทีโดยมีหนามแหลมเล็กน้อยถึงไม่เกิน 40 มิลลิวินาที ขนาดของหัวข้อคือ 100kb

PFB จุดข้อมูลเพิ่มเติมเกี่ยวกับ KAFKA และ RabbitMQ: Apache Kafka รวมถึงโบรกเกอร์เองซึ่งจริงๆแล้วเป็นที่รู้จักกันดีและเป็นที่นิยมมากที่สุดของมันและได้รับการออกแบบและวางตลาดอย่างเด่นชัดต่อสถานการณ์การประมวลผลสตรีม นอกจากนั้น Apache Kafka เพิ่งเพิ่ม Kafka Streams ซึ่งวางตำแหน่งตัวเองเป็นทางเลือกในการสตรีมแพลตฟอร์มเช่น Apache Spark, Apache Flink, Apache Beam / Google Cloud Data Flow และ Spring Cloud Data Flow เอกสารประกอบนั้นใช้งานได้ดีในการพูดคุยเกี่ยวกับกรณีการใช้งานที่ได้รับความนิยมเช่นการติดตามกิจกรรมเว็บไซต์ตัวชี้วัดการรวมบันทึกการประมวลผลสตรีมการจัดหากิจกรรมและบันทึกการกระทำ กรณีการใช้งานอย่างหนึ่งที่อธิบายคือการส่งข้อความซึ่งอาจสร้างความสับสนได้ ดังนั้นลองแกะกล่องออกมาสักเล็กน้อยเพื่อรับความชัดเจนว่าสถานการณ์การรับส่งข้อความใดดีที่สุดสำหรับ Kafka เช่น:

สตรีมจาก A ถึง B โดยไม่มีการกำหนดเส้นทางที่ซับซ้อนโดยมีปริมาณงานสูงสุด (100k / วินาที +) จัดส่งตามลำดับอย่างน้อยหนึ่งครั้ง เมื่อแอปพลิเคชันของคุณต้องการเข้าถึงประวัติสตรีมจัดส่งตามลำดับอย่างน้อยหนึ่งครั้ง คาฟคาเป็นร้านค้าข้อความที่มีความทนทานและลูกค้าสามารถรับ“ การเล่นซ้ำ” ของสตรีมกิจกรรมตามความต้องการซึ่งตรงข้ามกับโบรกเกอร์ข้อความแบบดั้งเดิมที่เมื่อส่งข้อความแล้วมันจะถูกลบออกจากคิว การประมวลผลเหตุการณ์การจัดหาสตรีม RabbitMQ เป็นโซลูชันการส่งข้อความทั่วไปซึ่งมักจะใช้เพื่ออนุญาตให้เว็บเซิร์ฟเวอร์ตอบสนองต่อการร้องขอได้อย่างรวดเร็วแทนที่จะถูกบังคับให้ทำตามขั้นตอนการใช้ทรัพยากรจำนวนมากในขณะที่ผู้ใช้รอผล นอกจากนี้ยังเป็นสิ่งที่ดีสำหรับการกระจายข้อความไปยังผู้รับหลายคนเพื่อการบริโภคหรือเพื่อสร้างสมดุลระหว่างคนงานที่มีภาระงานสูง (20k + / วินาที) เมื่อความต้องการของคุณขยายเกินกว่าปริมาณงาน RabbitMQ มีสิ่งที่จะนำเสนอมากมาย: คุณสมบัติสำหรับการจัดส่งที่เชื่อถือได้การกำหนดเส้นทางสหพันธรัฐ HA ความปลอดภัยเครื่องมือการจัดการและคุณสมบัติอื่น ๆ ตรวจสอบบางสถานการณ์ที่ดีที่สุดสำหรับ RabbitMQ เช่น:

แอปพลิเคชันของคุณต้องทำงานร่วมกับโปรโตคอลที่มีอยู่เช่น AMQP 0-9-1, STOMP, MQTT, AMQP 1.0 คุณต้องมีการควบคุม / การรับรองความมั่นคงที่ละเอียดยิ่งขึ้นต่อข้อความ (คิวจดหมายที่ตายแล้ว ฯลฯ ) อย่างไรก็ตาม Kafka ได้เพิ่มการสนับสนุนธุรกรรมที่ดีขึ้นเมื่อเร็ว ๆ นี้ แอปพลิเคชันของคุณต้องการความหลากหลายในจุดต่อจุดร้องขอ / ตอบและเผยแพร่ / สมัครรับส่งข้อความการกำหนดเส้นทางที่ซับซ้อนไปยังผู้บริโภครวมบริการ / แอพเข้ากับตรรกะการกำหนดเส้นทางที่ไม่น่ารำคาญ RabbitMQ ความช่วยเหลือของซอฟต์แวร์เพิ่มเติม RabbitMQ มักใช้กับ Apache Cassandra เมื่อแอปพลิเคชันต้องการเข้าถึงประวัติสตรีมหรือด้วยปลั๊กอิน LevelDB สำหรับแอปพลิเคชันที่ต้องมีคิว "ไม่มีที่สิ้นสุด" แต่ฟีเจอร์เหล่านี้ไม่ได้มาพร้อมกับ RabbitMQ

คำตอบสั้น ๆ คือ "ข้อความตอบรับ" RabbitMQ สามารถกำหนดค่าให้ต้องการข้อความตอบรับ หากผู้รับล้มเหลวข้อความจะกลับไปที่คิวและผู้รับอื่นสามารถลองอีกครั้ง ในขณะที่คุณสามารถทำสิ่งนี้ได้ใน Kafka ด้วยรหัสของคุณเองมันสามารถทำงานได้กับ RabbitMQ นอกกรอบ

จากประสบการณ์ของฉันหากคุณมีแอพพลิเคชั่นที่มีข้อกำหนดในการสืบค้นกระแสข้อมูล Kafka และ KSql เป็นทางออกที่ดีที่สุดของคุณ หากคุณต้องการระบบการเข้าคิวคุณจะดีขึ้นด้วย RabbitMQ

คำตอบที่ได้รับการโหวตมากที่สุดครอบคลุมส่วนใหญ่ แต่ฉันต้องการใช้มุมมองกรณีใช้แสงสูง คาฟคาทำกระต่าย mq ได้คำตอบคือใช่ แต่กระต่ายเอ็มเคสามารถทำทุกอย่างที่คาฟก้าทำได้คำตอบคือไม่ ดังนั้นสิ่งที่ Rabbit mq ไม่สามารถทำได้คือทำให้ kafka แตกต่างกันนั่นคือการกระจายการประมวลผลข้อความ ด้วยวิธีนี้อ่านคำตอบที่ได้รับการโหวตมากที่สุดในตอนนี้และจะทำให้เข้าใจได้ง่ายขึ้น หากต้องการทำอย่างละเอียดให้ใช้กรณีการใช้งานที่คุณต้องสร้างระบบการส่งข้อความที่มีปริมาณงานสูงเช่น "ชอบ" ใน Facebook และคุณได้เลือกกระต่าย mq สำหรับสิ่งนั้น คุณสร้างการแลกเปลี่ยนและคิวและผู้บริโภคที่ผู้เผยแพร่ทั้งหมด (ในกรณีนี้ผู้ใช้ FB) สามารถเผยแพร่ข้อความ 'ไลค์' เนื่องจากปริมาณงานของคุณสูง คุณจะสร้างหลายเธรดในคอนซูเมอร์เพื่อประมวลผลข้อความในแบบคู่ขนาน แต่คุณยังคงถูก จำกัด ด้วยความจุของฮาร์ดแวร์ของเครื่องที่ผู้ใช้บริการกำลังทำงานอยู่ สมมติว่าผู้บริโภครายหนึ่งไม่เพียงพอที่จะประมวลผลข้อความทั้งหมด - คุณจะทำอย่างไร คุณสามารถเพิ่มผู้บริโภคได้อีกหนึ่งรายในคิว - ไม่สามารถทำเช่นนั้นได้ คุณสามารถสร้างคิวใหม่และผูกคิวนั้นเพื่อแลกเปลี่ยนข้อความที่ 'ชอบ' เผยแพร่คำตอบนั้นไม่ทำให้คุณได้รับข้อความที่ประมวลผลสองครั้ง นั่นคือปัญหาหลักที่คาฟคาแก้ได้ มันช่วยให้คุณสร้างพาร์ติชันแบบกระจาย (Queue in rabbit mq) และผู้บริโภคแบบกระจายที่พูดคุยกัน ที่ทำให้ข้อความของคุณในหัวข้อได้รับการประมวลผลจากผู้บริโภคที่กระจายอยู่ในโหนดต่าง ๆ (Machines) โบรกเกอร์ของ Kafka รับประกันว่าข้อความจะได้รับความสมดุลในทุกส่วนของหัวข้อนั้น ๆ กลุ่มผู้บริโภคต้องแน่ใจว่าผู้บริโภคทุกคนพูดคุยกันและข้อความไม่ได้รับการดำเนินการสองครั้ง แต่ในชีวิตจริงคุณจะไม่ประสบกับปัญหานี้เว้นแต่ว่าคุณจะใส่ได้สูงเพราะ Rabbit mq สามารถประมวลผลข้อมูลได้อย่างรวดเร็วแม้กับผู้ใช้รายเดียว