引言 分散式系統中,我們廣泛運用消息中間件進行系統間的數據交換,便於非同步解耦。現在開源的消息中間件有很多,目前對Kafka、RabbitMQ、RocketMQ這三個消息中間件做下對比分析。 摘自:https://blog.csdn.net/wuzhengfei1112/article/details ...
引言
分散式系統中,我們廣泛運用消息中間件進行系統間的數據交換,便於非同步解耦。現在開源的消息中間件有很多,目前對Kafka、RabbitMQ、RocketMQ這三個消息中間件做下對比分析。
| - | - | kafka | RocketMQ | RabbitMQ | 數據來源 | 相關文章 |
| 定位 | 設計定位 | 系統間的數據流管道，實時數據處理。 例如：常規的消息系統、網站活性跟蹤，監控數據，日誌收集、處理等 |
非日誌的可靠消息傳輸。 例如：訂單，交易，充值，流計算，消息推送，日誌流式處理，binglog分發等 |
可靠消息傳輸。和RocketMQ類似。 | ||
| 基礎對比 | 成熟度 | 日誌領域成熟 | 成熟 | 成熟 | ||
| 所屬社區／公司 | Apache | Alibaba開發，已加入到Apache下 | Mozilla Public License | |||
| 社區活躍度 | 高 | 中 | 高 | 來源於網路 | ||
| API完備性 | 高 | 高 | 高 | |||
| 文檔完備性 | 高 | 高 | 高 | 來源於網路 | ||
| 開發語言 | Scala | Java | Erlang | |||
| 支持協議 | 一套自行設計的基於TCP的二進位協議 | 自己定義的一套 (社區提供JMS--不成熟) |
AMQP | |||
| 客戶端語言 | C/C++、Python、Go、Erlang、.NET、Ruby、Node.js、PHP等 | Java | Java、C、 C++、 Python、 PHP、Perl 等 | |||
| 持久化方式 | 磁碟文件 | 磁碟文件 | 記憶體、文件 | |||
| 可用性、可靠性比較 | 部署方式 | 單機／集群 | 單機／集群 | 單機／集群 | ||
| 集群管理 | zookeeper | name server | ||||
| 選主方式 | 從ISR中自動選舉一個leader | 不支持自動選主。通過設定brokername、brokerId實現，brokername相同，brokerid=0時為maser，其他為slave | 最早加入集群的broker | |||
| 可用性 | 非常高 分散式、主從 |
非常高 分散式、主從 |
高 主從，採用鏡像模式實現，數據量大時可能產生性能瓶頸 |
rabbitMQ集群部署 http://www.cnblogs.com/knowledgesea/p/6535766.html RabbitMQ可用性、可靠性分析 http://blog.csdn.net/cadem/article/details/53422912?utm_source=itdadao&utm_medium=referral |
||
| 主從切換 | 自動切換 N個副本，允許N-1個失效；master失效以後自動從isr中選擇一個主； |
不支持自動切換 master失效以後不能向master發送信息，consumer大概30s（預設）可以感知此事件，此後從slave消費；如果master無法恢復，非同步複製時可能出現部分信息丟失 |
自動切換 最早加入集群的slave會成為master；因為新加入的slave不同步master之前的數據，所以可能會出現部分數據丟失 |
|||
| 數據可靠性 | 很好 支持producer單條發送、同步刷盤、同步複製、非同步。 |
很好 producer單條發送，broker端支持同步刷盤、非同步刷盤，同步雙寫，非同步複製。 |
好 producer支持同步／非同步ack。支持隊列數據持久化，鏡像模式中支持主從同步 |
kafka也同步刷盤，但是效率較低 http://jm.taobao.org/2016/04/28/kafka-vs-rocktemq-4/ |
||
| 消息寫入性能 | 非常好 每條10個位元組測試：百萬條/s |
很好 每條10個位元組測試：單機單broker約7w/s，單機3個broker約12w/s |
RAM約為RocketMQ的1/2， Disk的性能約為RAM性能的1/3 |
數據來源於網路 單條消息的數據量越小，性能對比時kafka表現越好 |
kafka vs RocktMQ： https://engineering.linkedin.com/kafka/benchmarking-apache-kafka-2-million-writes-second-three-cheap-machines kafka vs RocktMQ VS RabbitMQ http://www.cnblogs.com/felixzh/p/6198070.html http://ju.outofmemory.cn/entry/177937 |
|
| 性能的穩定性 | 隊列/分區多時性能不穩定，明顯下降。 消息堆積時性能穩定 |
隊列較多、消息堆積時性能穩定 | 消息堆積時，性能不穩定、明顯下降 | |||
| 單機支持的隊列數 | 單機超過64個隊列/分區，Load會發生明顯的飆高現象，隊列越多，load越高，發送消息響應時間變長 | 單機支持最高5萬個隊列，Load不會發生明顯變化 | 依賴於記憶體 | 數據來源於網路測評 kafka新能降低是因為topic增多時，順序寫變成了隨機寫 |
Kafka vs RocketMQ: Topic數量對單機性能的影響 http://jm.taobao.org/2016/04/07/kafka-vs-rocketmq-topic-amout/?utm_source=tuicool&utm_medium=referral |
|
| 堆積能力 | 非常好 消息存儲在log中，每個分區由一個或多個segment log文件 |
非常好 所有消息存儲在同一個commit log中 |
一般 生產者、消費者正常時，性能表現穩定；消費者不消費時，性能不穩定 |
http://www.cnblogs.com/purpleraintear/p/6033136.html | ||
| 複製備份 | 消息先寫入leader的log，followers從leader中pull數據，pull到數據以後先ack leader，然後寫入log中。 ISR中維護與leader同步的列表，落後太多的follwer會被刪除掉 |
同步雙寫 非同步複製：slave啟動線程從master中拉數據 |
普通模式下不複製； 鏡像模式下：消息先到mster，然後寫到slave上。加入集群之前的消息不會被覆制到新的slave上。 |
|||
| 消息投遞實時性 | 毫秒級 具體由consumer輪詢間隔時間決定 |
毫秒級 支持pull、push兩種模式，延時通常在毫秒級 |
毫秒級 | |||
| 功能對比 | 順序消費 | 支持順序消費 但是一臺Broker宕機後，就會產生消息亂序(來自網上，尚未找到原因） |
支持順序消費 在順序消息場景下，消費失敗時消費隊列將會暫停 |
支持順序消費 | ||
| 定時消息 | 不支持 | 開源版本僅支持定時Level | 不支持 | |||
| 事務消息 | 不支持 | 支持 | 不支持 | |||
| Broker端消息過濾 | 不支持 | 支持 通過tag過濾，類似於子topic |
不支持 | |||
| 消息查詢 | 不支持 | 支持 根據MessageId查詢 支持根據MessageKey查詢消息 |
不支持 | |||
| 消費失敗重試 | 不支持失敗重試 offset存儲在consumer中，無法保證。 0.8.2版本後支持將offset存儲在zk中 |
支持失敗重試 offset存儲在broker中 |
支持失敗重試 | |||
| 消息重新消費 | 支持通過修改offset來重新消費 | 支持按照時間來重新消息 | ||||
| 發送端負載均衡 | 可自由指定 | 可自由指定 | 需要單獨loadbalancer支持 | |||
| 消費並行度 | 消費並行度和分區數一致 | 順序消費：消費並行度和分區數一致 亂序消費：消費伺服器的消費線程數之和 |
可一次抓取多條一起消費。 鏡像模式下其實也是從master消費 |
|||
| 消費方式 | consumer pull | consumer pull ／broker push | broker push | |||
| 批量發送 | 支持 預設producer緩存、壓縮，然後批量發送 |
不支持 | 不支持 | |||
| 消息清理 | 指定文件保存時間，過期刪除 | 指定文件保存時間，過期刪除 | Consumer ack以後，消息將被標記為刪除 可用記憶體少於40%（預設），觸發gc，gc時找到相鄰的兩個文件，合併right文件到left。 |
|||
| 運維 | 系統維護 | Scala語言開發，維護成本高 | java語言開發，維護成本低 | Erlang語言開發，維護成本高 | ||
| 部署依賴 | zookeeper | nameserver | Erlang環境 | |||
| 管理後臺 | 官網不提供，第三方開源管理工具可供使用；不用重新開發 | 官方提供，rocketmq-console | 官方提供rabbitmqadmin | kafka管理後臺比較；http://top.jobbole.com/31084/ | ||
| 管理後臺功能 | Kafka Web Conslole Brokers列表；Kafka 集群中 Topic列表，及對應的Partition、LogSize等信息；Topic對應的Consumer Groups、Offset、Lag等信息； 生產和消費流量圖、消息預覽 KafkaOffsetMonitor： Kafka集群狀態；Topic、Consumer Group列表；圖形化展示topic和consumer之間的關係；圖形化展示consumer的Offset、Lag等信息 Kafka Manager 管理幾個不同的集群；監控集群的狀態(topics, brokers, 副本分佈, 分區分佈)；產生分區分配(Generate partition assignments)基於集群的當前狀態；重新分配分區 |
Cluster、Topic、Connection、NameServ、Message、Broker、Offset、Consumer | overview、connections、channels、exchanges、queues、admin | |||
| 總結 | 優點 | 1、在高吞吐、低延遲、高可用、集群熱擴展、集群容錯上有非常好的表現； 2、producer端提供緩存、壓縮功能，可節省性能，提高效率。 3、提供順序消費能力 4、提供多種客戶端語言 5、生態完善，在大數據處理方面有大量配套的設施。 |
1、在高吞吐、低延遲、高可用上有非常好的表現；消息堆積時，性能也很好。 2、api、系統設計都更加適在業務處理的場景。 3、支持多種消費方式。 4、支持broker消息過濾。 5、支持事務。 6、提供消息順序消費能力；consumer可以水平擴展，消費能力很強。 7、集群規模在50台左右，單日處理消息上百億；經歷過大數據量的考驗，比較穩定可靠。 |
1、在高吞吐量、高可用上較前兩者有所不如。 2、支持多種客戶端語言；支持amqp協議。 3、由於erlang語言的特性，性能也比較好; 使用RAM模式時，性能很好。 4、管理界面較豐富，在互聯網公司也有較大規模的應用; |
數據來自網路 | |
| 缺點 | 1、消費集群數目受到分區數目的限制。 2、單機topic多時，性能會明顯降低。 3、不支持事務 |
1、相比於kafka，使用者較少，生態不夠完善。消息堆積、吞吐率上也有所不如。 2、不支持主從自動切換，master失效後，消費者需要一定的時間才能感知。 3、客戶端只支持Java |
1、erlang 語言難度較大。集群不支持動態擴展。 2、不支持事務、消息吞吐能力有限 3、消息堆積時，性能會明顯降低 |
摘自:https://blog.csdn.net/wuzhengfei1112/article/details/78069645
