Có bất kỳ lý do để sử dụng RabbitMQ trên Kafka?

Tôi đã được yêu cầu đánh giá RabbitMQ thay vì Kafka nhưng thật khó để tìm ra lý do rằng nó làm điều gì đó tốt hơn Kafka. Có ai biết nếu nó thực sự tốt hơn về thông lượng, độ bền, độ trễ, hoặc dễ sử dụng?

RabbitMQ là một nhà môi giới tin nhắn đa năng, vững chắc, hỗ trợ một số giao thức như AMQP, MQTT, STOMP, v.v. Nó có thể xử lý thông lượng cao. Trường hợp sử dụng phổ biến cho RabbitMQ là xử lý các công việc nền hoặc tác vụ dài hạn, chẳng hạn như quét tệp , chia tỷ lệ hình ảnh hoặc chuyển đổi PDF. RabbitMQ cũng được sử dụng giữa các dịch vụ siêu nhỏ, nơi nó phục vụ như một phương tiện giao tiếp giữa các ứng dụng, tránh tắc nghẽn khi truyền tin nhắn.

Kafka là một bus tin nhắn được tối ưu hóa cho các luồng dữ liệu xâm nhập cao và phát lại. Sử dụng Kafka khi bạn có nhu cầu di chuyển một lượng lớn dữ liệu, xử lý dữ liệu theo thời gian thực hoặc phân tích dữ liệu trong một khoảng thời gian. Nói cách khác, nơi dữ liệu cần được thu thập, lưu trữ và xử lý. Một ví dụ là khi bạn muốn theo dõi hoạt động của người dùng trên webshop và tạo các mục được đề xuất để mua. Một ví dụ khác là phân tích dữ liệu để theo dõi, nhập, ghi nhật ký hoặc bảo mật.

Kafka có thể được coi là một nhà môi giới tin nhắn bền , nơi các ứng dụng có thể xử lý và xử lý lại dữ liệu truyền phát trên đĩa. Kafka có một cách tiếp cận định tuyến rất đơn giản. RabbitMQ có các tùy chọn tốt hơn nếu bạn cần định tuyến tin nhắn của mình theo những cách phức tạp đến người tiêu dùng. Sử dụng Kafka nếu bạn cần hỗ trợ hàng loạt người tiêu dùng có thể ngoại tuyến hoặc người tiêu dùng muốn nhắn tin ở độ trễ thấp. 

Để hiểu cách đọc dữ liệu từ Kafka, trước tiên chúng ta cần hiểu người tiêu dùng và nhóm người tiêu dùng của nó. Phân vùng cho phép bạn song song hóa một chủ đề bằng cách chia dữ liệu trên nhiều nút. Mỗi bản ghi trong một phân vùng được gán và xác định bởi phần bù duy nhất của nó. Điều này bù vào điểm ghi trong một phân vùng. Trong phiên bản mới nhất của Kafka, Kafka duy trì một số bù cho mỗi bản ghi trong một phân vùng. Một người tiêu dùng ở Kafka có thể tự động cam kết giảm giá theo định kỳ hoặc có thể chọn kiểm soát vị trí đã cam kết này theo cách thủ công. RabbitMQ sẽ giữ tất cả các trạng thái về các tin nhắn đã tiêu thụ / thừa nhận / chưa được xác nhận. Tôi thấy Kafka phức tạp hơn để hiểu hơn trường hợp của RabbitMQ, trong đó tin nhắn chỉ đơn giản là bị xóa khỏi hàng đợi một khi nó được gửi đi.

Hàng đợi của RabbitMQ nhanh nhất khi chúng trống, trong khi Kafka giữ lại một lượng lớn dữ liệu với rất ít chi phí - Kafka được thiết kế để giữ và phân phối khối lượng lớn tin nhắn. (Nếu bạn dự định có hàng đợi rất dài trong RabbitMQ, bạn có thể xem hàng đợi lười biếng .)

Kafka được xây dựng từ mặt đất lên với tỷ lệ ngang (tỷ lệ bằng cách thêm nhiều máy), trong khi RabbitMQ chủ yếu được thiết kế để mở rộng theo chiều dọc (tỷ lệ bằng cách thêm nhiều năng lượng hơn).

RabbitMQ có giao diện thân thiện với người dùng tích hợp cho phép bạn giám sát và xử lý máy chủ RabbitMQ của mình từ trình duyệt web. Trong số những thứ khác, hàng đợi, kết nối, kênh, trao đổi, người dùng và quyền người dùng có thể được xử lý - tạo, xóa và liệt kê trong trình duyệt và bạn có thể theo dõi tốc độ tin nhắn và gửi / nhận tin nhắn theo cách thủ công. Kafka có một số công cụ nguồn mở và một số công cụ thương mại một lần , cung cấp các chức năng quản trị và giám sát. Tôi sẽ nói rằng nó dễ dàng hơn / nhanh hơn để hiểu rõ hơn về RabbitMQ.

Đọc thêm và một số dữ liệu so sánh có thể được tìm thấy ở đây: https://www.cloudamqp.com/blog/2019-12-12-when-to-use-rabbitmq-or-apache-kafka.html

Đồng thời giới thiệu bài báo trong ngành: "Kafka so với RabbitMQ: Một nghiên cứu so sánh về hai triển khai đăng ký / đăng ký tham khảo ngành": http://dl.acm.org/citation.cfm?id=3093908

Tôi làm việc tại một công ty cung cấp cả Apache Kafka và RabbitMQ dưới dạng Dịch vụ.

Tôi nghe câu hỏi này mỗi tuần ... Trong khi RabbitMQ (như IBM MQ hoặc JMS hoặc các giải pháp nhắn tin khác nói chung) được sử dụng cho nhắn tin truyền thống, Apache Kafka được sử dụng làm nền tảng phát trực tuyến (nhắn tin + lưu trữ phân tán + xử lý dữ liệu). Cả hai đều được xây dựng cho các trường hợp sử dụng khác nhau.

Bạn có thể sử dụng Kafka cho "nhắn tin truyền thống", nhưng không sử dụng MQ cho các tình huống cụ thể của Kafka.

Bài viết về Apache Apache Kafka so với Enterprise Service Bus (ESB) Bạn bè, Kẻ thù hay Kẻ thù? ( https://www.confluent.io/blog/apache-kafka-vs-enterprise-service-bus-esb-friends-en Kẻ-or-fren Kẻ / ), thảo luận về lý do tại sao Kafka không cạnh tranh nhưng bổ sung cho các giải pháp tích hợp và nhắn tin (bao gồm RabbitMQ) và cách tích hợp cả hai.

5 Sự khác biệt chính giữa Kafka và RabbitMQ, khách hàng đang sử dụng chúng:

Chọn hệ thống nhắn tin nào hoặc chúng ta nên thay đổi hệ thống nhắn tin hiện tại?

Không có ai trả lời cho câu hỏi trên. Một cách tiếp cận khả thi để xem xét khi bạn phải quyết định hệ thống nhắn tin nào hoặc bạn nên thay đổi hệ thống hiện tại là sang Đánh giá quy mô và chi phí ”

Một điểm khác biệt quan trọng mà các bạn quên là RabbitMQ là hệ thống nhắn tin dựa trên đẩy trong khi Kafka là hệ thống nhắn tin dựa trên kéo. Điều này rất quan trọng trong kịch bản mà hệ thống nhắn tin phải đáp ứng các loại người tiêu dùng khác nhau với các khả năng xử lý khác nhau. Với hệ thống dựa trên Pull, người tiêu dùng có thể tiêu thụ dựa trên khả năng của họ, nơi các hệ thống đẩy sẽ đẩy các thông điệp bất kể trạng thái của người tiêu dùng do đó khiến người tiêu dùng gặp rủi ro cao.

RabbitMQ là một nhà môi giới tin nhắn mục đích chung truyền thống. Nó cho phép các máy chủ web trả lời các yêu cầu một cách nhanh chóng và gửi tin nhắn đến nhiều dịch vụ. Các nhà xuất bản có thể xuất bản tin nhắn và cung cấp chúng cho hàng đợi để người tiêu dùng có thể truy xuất chúng. Giao tiếp có thể không đồng bộ hoặc đồng bộ.

Mặt khác, Apache Kafka không chỉ là một nhà môi giới tin nhắn. Ban đầu nó được LinkedIn thiết kế và triển khai để phục vụ như một hàng đợi tin nhắn. Từ năm 2011, Kafka đã được mở nguồn và nhanh chóng phát triển thành một nền tảng phát trực tuyến phân tán, được sử dụng để thực hiện các đường ống dữ liệu thời gian thực và các ứng dụng phát trực tuyến.

Nó có khả năng mở rộng theo chiều ngang, chịu lỗi, nhanh chóng hoạt động và được sản xuất trong hàng ngàn công ty.

Các tổ chức hiện đại có các đường ống dữ liệu khác nhau tạo điều kiện thuận lợi cho việc liên lạc giữa các hệ thống hoặc dịch vụ. Mọi thứ trở nên phức tạp hơn một chút khi một số lượng dịch vụ hợp lý cần liên lạc với nhau theo thời gian thực.

Kiến trúc trở nên phức tạp do các tích hợp khác nhau được yêu cầu để cho phép liên lạc giữa các dịch vụ này. Chính xác hơn, đối với một kiến ​​trúc bao gồm m nguồn và n dịch vụ đích, cần phải viết các tích hợp riêng biệt nxm. Ngoài ra, mọi tích hợp đều đi kèm với một đặc điểm kỹ thuật khác nhau, có nghĩa là người ta có thể yêu cầu một giao thức khác nhau (HTTP, TCP, JDBC, v.v.) hoặc biểu diễn dữ liệu khác nhau (Binary, Apache Avro, JSON, v.v.), khiến mọi thứ trở nên khó khăn hơn . Hơn nữa, các dịch vụ nguồn có thể giải quyết tải tăng từ các kết nối có khả năng ảnh hưởng đến độ trễ.

Apache Kafka dẫn đến các kiến ​​trúc đơn giản và dễ quản lý hơn, bằng cách tách các đường ống dữ liệu. Kafka hoạt động như một hệ thống phân tán thông lượng cao, nơi các dịch vụ nguồn đẩy luồng dữ liệu, làm cho chúng có sẵn cho các dịch vụ mục tiêu để kéo chúng theo thời gian thực.

Ngoài ra, hiện có rất nhiều Giao diện người dùng cấp độ doanh nghiệp và nguồn mở để quản lý các cụm Kafka. Để biết thêm chi tiết, hãy tham khảo các bài viết của tôi Tổng quan về các công cụ giám sát UI cho các cụm Kafka của Apache và Tại sao lại là Apache Kafka?

Quyết định về việc đi RabbitMQ hay Kafka tùy thuộc vào yêu cầu của dự án của bạn. Nói chung, nếu bạn muốn một nhà môi giới tin nhắn pub-sub đơn giản / truyền thống thì hãy đến với RabbitMQ. Nếu bạn muốn xây dựng một kiến ​​trúc hướng sự kiện trên đó tổ chức của bạn sẽ hành động theo các sự kiện trong thời gian thực, thì hãy tìm đến Apache Kafka vì nó cung cấp nhiều chức năng hơn cho loại kiến ​​trúc này (ví dụ Kafka Streams hoặc ksqlDB).

Tôi biết điều đó hơi muộn và có thể bạn đã gián tiếp nói điều đó, nhưng một lần nữa, Kafka hoàn toàn không phải là một hàng đợi, đó là một bản ghi (như ai đó đã nói ở trên, dựa trên cuộc thăm dò ý kiến).

Để đơn giản hóa, trường hợp sử dụng rõ ràng nhất khi bạn nên sử dụng RabbitMQ (hoặc bất kỳ kỹ thuật xếp hàng nào) so với Kafka là trường hợp sau:

Bạn có nhiều người tiêu dùng tiêu thụ từ một hàng đợi và bất cứ khi nào có một tin nhắn mới trong hàng đợi và một người tiêu dùng có sẵn, bạn muốn tin nhắn này được xử lý. Nếu bạn nhìn kỹ vào cách Kafka hoạt động, bạn sẽ nhận thấy nó không biết làm thế nào, vì quy mô phân vùng, bạn sẽ có một người tiêu dùng dành riêng cho một phân vùng và bạn sẽ gặp vấn đề chết đói. Vấn đề dễ dàng tránh được bằng cách sử dụng kỹ thuật xếp hàng đơn giản. Bạn có thể nghĩ đến việc sử dụng một luồng sẽ gửi các thông điệp khác nhau từ cùng một phân vùng, nhưng một lần nữa, Kafka không có bất kỳ cơ chế xác nhận chọn lọc nào.

Điều tốt nhất bạn có thể làm là làm những kẻ đó và cố gắng biến Kafka thành một hàng đợi: https://github.com/softwaremill/kmq

Yannick

Tôi sẽ cung cấp một câu trả lời khách quan dựa trên kinh nghiệm của tôi với cả hai, tôi cũng sẽ bỏ qua lý thuyết đằng sau chúng, giả sử bạn đã biết và / hoặc các câu trả lời khác đã cung cấp đủ.

ThỏMQ : Tôi sẽ chọn cái này nếu yêu cầu của tôi đủ đơn giản để xử lý giao tiếp hệ thống thông qua các kênh / hàng đợi, việc duy trì và phát trực tuyến không phải là một yêu cầu. Ví dụ: Khi hệ thống sản xuất xây dựng tài sản, nó sẽ thông báo cho hệ thống thỏa thuận để định cấu hình hợp đồng, v.v.

Kafka : Yêu cầu tìm nguồn cung ứng sự kiện là chủ yếu, khi bạn có thể cần xử lý các luồng (đôi khi là vô hạn), một lượng dữ liệu khổng lồ ngay lập tức được cân bằng chính xác, phát lại bù đắp để đảm bảo trạng thái nhất định, v.v. Hãy nhớ rằng kiến ​​trúc này cũng mang lại sự phức tạp hơn, vì nó bao gồm các khái niệm như chủ đề / phân vùng / môi giới / thông điệp bia mộ, v.v. như một tầm quan trọng hạng nhất.

Sử dụng RabbitMQ khi:

• Bạn không phải xử lý với Bigdata và bạn thích giao diện người dùng được xây dựng thuận tiện để theo dõi
• Không cần hàng đợi tự động sao chép
• Không có nhiều người đăng ký cho các tin nhắn - Vì không giống như Kafka là nhật ký, RabbitMQ là một hàng đợi và các tin nhắn được xóa sau khi tiêu thụ và đã có xác nhận
• Nếu bạn có yêu cầu sử dụng Ký tự đại diện và biểu thức chính quy cho tin nhắn
• Nếu xác định ưu tiên tin nhắn là quan trọng

Tóm lại: RabbitMQ phù hợp với các trường hợp sử dụng đơn giản, với lưu lượng dữ liệu thấp, với lợi ích của hàng đợi ưu tiên và các tùy chọn định tuyến linh hoạt. Đối với dữ liệu lớn và thông lượng cao sử dụng Kafka.

Lợi ích duy nhất mà tôi có thể nghĩ đến là tính năng Giao dịch, phần còn lại có thể được thực hiện bằng cách sử dụng Kafka

Thu nhỏ cả hai đều khó theo cách chịu lỗi phân tán nhưng tôi sẽ tạo ra một trường hợp khó hơn nhiều ở quy mô lớn với RabbitMQ. Việc hiểu Xẻng, Liên đoàn, Nhân đôi Msg Queue, ACK, Mem vấn đề, Taultance v.v ... Không phải là không có vấn đề cụ thể với Zookeeper, v.v. trên Kafka nhưng có ít bộ phận chuyển động hơn để quản lý. Điều đó nói rằng, bạn nhận được một trao đổi Polyglot với RMQ mà bạn không có với Kafka. Nếu bạn muốn phát trực tuyến, hãy sử dụng Kafka. Nếu bạn muốn phân phối gói IoT đơn giản hoặc khối lượng lớn tương tự, hãy sử dụng Kafka. Đó là về người tiêu dùng thông minh. Nếu bạn muốn tính linh hoạt của tin nhắn và độ tin cậy cao hơn với chi phí cao hơn và có thể phức tạp hơn, hãy sử dụng RMQ.

Nếu bạn có nhu cầu định tuyến phức tạp và muốn có GUI tích hợp để giám sát nhà môi giới, thì RabbitMQ có thể là tốt nhất cho ứng dụng của bạn. Mặt khác, nếu bạn đang tìm kiếm một nhà môi giới tin nhắn để xử lý thông lượng cao và cung cấp quyền truy cập vào lịch sử truyền phát, Kafka có thể là sự lựa chọn tốt hơn.

Apache Kafka là một lựa chọn phổ biến để cung cấp năng lượng cho các đường ống dữ liệu. Apache kafka đã thêm luồng kafka để hỗ trợ các trường hợp sử dụng etl phổ biến. KSQL giúp đơn giản hóa việc chuyển đổi dữ liệu trong đường ống, sẵn sàng thông báo để hạ cánh sạch sẽ trong hệ thống khác. KSQL là công cụ phát trực tuyến SQL cho Apache Kafka. Nó cung cấp một giao diện SQL tương tác dễ sử dụng nhưng mạnh mẽ để xử lý luồng trên Kafka, mà không cần phải viết mã bằng ngôn ngữ lập trình như Java hoặc Python. KSQL có khả năng mở rộng, đàn hồi, chịu lỗi và thời gian thực. Nó hỗ trợ một loạt các hoạt động phát trực tuyến, bao gồm lọc dữ liệu, biến đổi, tập hợp, tham gia, cửa sổ và phiên.

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

Rabbitmq không phải là một lựa chọn phổ biến cho các hệ thống etl thay vì các hệ thống mà nó yêu cầu các hệ thống nhắn tin đơn giản với ít thông lượng hơn.

Tôi nhận ra rằng đây là một câu hỏi cũ, nhưng một kịch bản mà RabbitMQ có thể là lựa chọn tốt hơn là khi xử lý việc chuyển đổi dữ liệu.

Với RabbitMQ, theo mặc định một khi tin nhắn đã được sử dụng, nó sẽ bị xóa. Với Kafka, theo mặc định, tin nhắn được giữ trong một tuần. Việc đặt nó ở thời gian lâu hơn hoặc thậm chí không bao giờ xóa chúng là điều phổ biến.

Mặc dù cả hai sản phẩm đều có thể được định cấu hình để giữ lại (hoặc không giữ lại) tin nhắn, nếu tuân thủ CCPA hoặc GDPR là một mối quan tâm, tôi sẽ đi với RabbitMQ.

Kafka tốt hơn RabbitMQ về thông lượng, độ bền, độ trễ. Nếu bạn đang mong đợi các giao dịch dưới 10k / giây thì bạn có thể truy cập RabbitMQ, nhưng điều đó cũng phụ thuộc vào việc triển khai của bạn.

Tôi đã triển khai Kafka trong sản phẩm của chúng tôi, nơi chúng tôi đã xử lý hơn 70k / giây giao dịch và độ trễ trung bình là 15ms với một vài đột biến đạt tới 40ms. Kích thước chủ đề là 100kb.

PFB nhiều điểm dữ liệu hơn trên KAFKA và RabbitMQ: Apache Kafka bao gồm chính nhà môi giới, đây thực sự là phần nổi tiếng nhất và phổ biến nhất của nó, và đã được thiết kế và tiếp thị nổi bật theo các kịch bản xử lý luồng. Ngoài ra, Apache Kafka gần đây đã thêm Luồng Kafka, vị trí thay thế cho các nền tảng phát trực tuyến như Apache Spark, Apache Flink, Apache Beam / Google Cloud Data Flow và Spring Cloud Data Flow. Tài liệu này thực hiện tốt công việc thảo luận về các trường hợp sử dụng phổ biến như Theo dõi hoạt động của trang web, Số liệu, Tổng hợp nhật ký, Xử lý luồng, Tìm nguồn sự kiện và Nhật ký cam kết. Một trong những trường hợp sử dụng mà nó mô tả là nhắn tin, có thể tạo ra một số nhầm lẫn. Vì vậy, hãy giải nén một chút và hiểu rõ hơn về kịch bản nhắn tin nào là tốt nhất cho Kafka, như:

Truyền phát từ A đến B mà không cần định tuyến phức tạp, với thông lượng tối đa (100k / giây +), được phân phối theo thứ tự phân vùng ít nhất một lần. Khi ứng dụng của bạn cần truy cập vào lịch sử truyền phát, hãy phân phối theo thứ tự phân vùng ít nhất một lần. Kafka là một kho lưu trữ tin nhắn bền bỉ và khách hàng có thể nhận được một phát lại trực tiếp các dòng sự kiện theo yêu cầu, trái ngược với các nhà môi giới tin nhắn truyền thống hơn khi một tin nhắn được gửi đi, nó sẽ bị xóa khỏi hàng đợi. Nguồn xử lý sự kiện Nguồn RabbitMQ là một giải pháp nhắn tin có mục đích chung, thường được sử dụng để cho phép các máy chủ web phản hồi nhanh chóng các yêu cầu thay vì buộc phải thực hiện các thủ tục nặng về tài nguyên trong khi người dùng chờ kết quả. Nó cũng tốt cho việc phân phối một tin nhắn cho nhiều người nhận để tiêu thụ hoặc để cân bằng tải giữa các công nhân dưới tải cao (20k + / giây). Khi các yêu cầu của bạn vượt quá thông lượng, RabbitMQ có rất nhiều thứ để cung cấp: các tính năng để phân phối đáng tin cậy, định tuyến, liên kết, HA, bảo mật, công cụ quản lý và các tính năng khác. Hãy xem xét một số tình huống tốt nhất cho RabbitMQ, như:

Ứng dụng của bạn cần hoạt động với mọi kết hợp các giao thức hiện có như AMQP 0-9-1, STOMP, MQTT, AMQP 1.0. Bạn cần một kiểm soát / đảm bảo tính nhất quán chi tiết hơn trên cơ sở mỗi tin nhắn (hàng đợi thư chết, v.v.) Tuy nhiên, Kafka gần đây đã thêm hỗ trợ tốt hơn cho các giao dịch. Ứng dụng của bạn cần đa dạng từ điểm tới điểm, yêu cầu / trả lời và xuất bản / đăng ký nhắn tin Định tuyến phức tạp tới người tiêu dùng, tích hợp nhiều dịch vụ / ứng dụng với logic định tuyến không tầm thường RabbitMQ cũng có thể giải quyết hiệu quả một số trường hợp sử dụng mạnh mẽ của Kafka ở trên, nhưng với trợ giúp của phần mềm bổ sung. RabbitMQ thường được sử dụng với Apache Cassandra khi ứng dụng cần truy cập vào lịch sử phát trực tuyến hoặc với trình cắm LevelDB cho các ứng dụng cần hàng đợi vô hạn của trò chơi, nhưng không có tính năng nào có bản thân RabbitMQ.

Câu trả lời ngắn gọn là "xác nhận tin nhắn". RabbitMQ có thể được cấu hình để yêu cầu xác nhận tin nhắn. Nếu một người nhận không thành công, tin nhắn sẽ quay trở lại hàng đợi và một người nhận khác có thể thử lại. Mặc dù bạn có thể thực hiện điều này trong Kafka bằng mã của riêng bạn, nhưng nó hoạt động với RabbitMQ ngay lập tức.

Theo kinh nghiệm của tôi, nếu bạn có một ứng dụng có yêu cầu truy vấn luồng thông tin, Kafka và KSql là lựa chọn tốt nhất của bạn. Nếu bạn muốn có một hệ thống xếp hàng, bạn nên sử dụng RabbitMQ.

Câu trả lời được bình chọn nhiều nhất bao gồm hầu hết các phần nhưng tôi muốn đưa ra quan điểm về trường hợp sử dụng ánh sáng cao. Có thể kafka làm điều đó mq thỏ có thể làm, câu trả lời là có nhưng thỏ mq có thể làm mọi thứ mà kafka làm không, câu trả lời là không. Vì vậy, điều mà mq thỏ không thể làm được khiến kafka trở nên khác biệt, đó là xử lý tin nhắn phân tán. Với điều này bây giờ đọc lại câu trả lời được bình chọn nhiều nhất và nó sẽ có ý nghĩa hơn. Để giải thích, hãy sử dụng trường hợp bạn cần tạo một hệ thống nhắn tin có thông lượng siêu cao, ví dụ như "lượt thích" trong facebook và Bạn đã chọn thỏ mq cho điều đó. Bạn đã tạo một trao đổi và xếp hàng và một người tiêu dùng nơi tất cả các nhà xuất bản (trong trường hợp này là người dùng FB) có thể xuất bản tin nhắn 'thích'. Vì thông lượng của bạn cao, bạn sẽ tạo nhiều luồng trong người tiêu dùng để xử lý các tin nhắn song song nhưng bạn vẫn bị giới hạn bởi dung lượng phần cứng của máy nơi người tiêu dùng đang chạy. Giả sử rằng một người tiêu dùng không đủ để xử lý tất cả các tin nhắn - bạn sẽ làm gì? Bạn có thể thêm một người tiêu dùng để xếp hàng - không bạn không thể làm điều đó. Bạn có thể tạo một hàng đợi mới và liên kết hàng đợi đó để trao đổi thông báo 'thích' không, câu trả lời là không có lý do gì bạn sẽ xử lý tin nhắn hai lần. Đó là vấn đề cốt lõi mà kafka giải quyết. Nó cho phép bạn tạo các phân vùng phân tán (Queue in rabbit mq) và người tiêu dùng phân tán nói chuyện với nhau. Điều đó đảm bảo thư của bạn trong một chủ đề được xử lý bởi người tiêu dùng được phân phối trong các nút khác nhau (Máy). Các nhà môi giới Kafka đảm bảo rằng các thông điệp được tải cân bằng trên tất cả các phân vùng của chủ đề đó. Nhóm người tiêu dùng đảm bảo rằng tất cả người tiêu dùng nói chuyện với nhau và tin nhắn không được xử lý hai lần. Nhưng trong cuộc sống thực, bạn sẽ không gặp phải vấn đề này trừ khi khả năng thông qua của bạn rất cao vì thỏ mq cũng có thể xử lý dữ liệu rất nhanh ngay cả với một người tiêu dùng.