標題:有任何理由去用兔兔MQ而非Kafka?
提問者:
我被要求評估使用兔兔MQ而非Kafka,但實在很難找到任何理由證明兔兔MQ比Kafka好.有任何人知道在吞吐量、持久性、延遲、或是容易使用方面真的有比較好嗎?
答者:
兔兔MQ是穩定的一般向的訊息代理,並且支援多種傳輸協定諸如:AMQP、MQTT、STOMP...等,它可以處理高吞吐量,且是一般情況下處理後端作業或作為微服務的訊息代理.而Kafka則是訊息車,特化了重磅訊息數據流的傳輸.
Kafka可被視作持久的訊息代理,應用程式可以處理或重新處理磁碟上的數據流.Kafka具有非常簡單的路由方法.兔兔MQ則針對複雜路由才能到達接收者的情況有更佳的選擇.若是在支援offline的批次的接收者(consumer),請使用Kafka,或者是接收者(consumer)只允許低延遲的訊息傳遞.
為了瞭解Kafka如果讀取資料,首先我們要瞭解Kafka定義的接收者與接收者群組.分塊(Partition)使您可以透過拆分數據到多個節點來並行一個主題.每個分塊(Partition)中的紀錄均由其唯一偏量(offset)分配與標識.此偏量(offset)指向分塊(Partition)中的記錄。 在最新版本的Kafka中，Kafka為分塊(Partition)中的每個記錄維護一個數字偏量(offset)。 Kafka中的接收者(consumer)可以定期自動提交偏量(offset)，也可以選擇手動控制此提交位置.兔兔MQ已保留所有已被接收/已確認/未確認的訊息的所有狀態。 我發現對於訊息一被確認後即刪除的部分，Kafka的理解比RabbitMQ更難理解.
RabbitMQ的隊列(queues)為空時最快,而Kafka則以很少的開銷保留了大量數據-Kafka旨在保存和分發大量消息.（如果您計劃在RabbitMQ中有很長的隊列,可以看看惰性隊列(lazy-queues).）
Kafka是從頭開始構建的,考慮到了水平縮放（通過添加更多機器來縮放）,而RabbitMQ主要是針對垂直縮放（通過增加更多功率來縮放）而設計的.
RabbitMQ具有內建的良好的界面,可讓您從瀏覽器監控和處理RabbitMQ服務器.隊列(queues),連接(connention),通道(channels),交換(exchanges),使用者們和單一使用者的權限等可以在瀏覽器中處理,創建,刪除和列出,您可以監視消息速率並手動發送/接收消息. Kafka有許多開源工具,還有一些商業工具,提供管理和監視功能.我想說,兔兔MQ比較容易入門.
還建議業界論文：“ Kafka與RabbitMQ：兩個行業參考發布/訂閱實現的比較研究”：
另外我本身是在一家提供Apache Kafka與兔兔MQ服務的公司任職.
