? ? ?在互聯網公司工作的RD們，對消息中間件最為熟悉不過了，如今隨著分布式系統架構的盛行。一個高可用、高并發的消息中間件對我們來說尤為重要。在公司快速增長時期，是沒有精力去研發這種基礎中間件。所以如何選擇就成了一個問題？這個問題也需要我們深入了解各個消息中間件的特性。我們就當前比較熱門的消息中間件淘寶開源的RocketMQ和linkin開源的kafka做一個橫向對比。就互聯網目前應用場景劃分。kafka更多的應用在日志傳輸上。但是對于交易、訂單、充值等對消息高要求的情況下有諸多特性不滿足。淘寶在借鑒kafka的原理的基礎上使用java開發了RocketMQ（kafka使用scala編程）。雖然RocketMQ定位于非日志可靠消息傳輸，但對日志場景也是支持的。目前阿里集團也被廣泛應用在訂單、交易、充值、流計算，消息推送，日志流處理，binglog分發等場景。我們從系統性能、消息機制、后期維護三個大的方面總結一下。一共16個特性。

系統性能

一、 數據庫可靠性

A：RocketMQ支持異步刷盤，同步刷盤，同步Replication，異步Replication

B：kafka使用異步刷盤方式，異步Replication

備注：RocketMQ的同步刷盤在單機可靠性上比Kafka更高，不會因為操作系統Crash，導致數據丟失。 同時同步Replication也比Kafka異步Replication更可靠，數據完全無單點。另外Kafka的Replication以topic為單位，支持主機宕機，備機自動切換，但是這里有個問題，由于是異步Replication，那么切換后會有數據丟失，同時Leader如果重啟后，會與已經存在的Leader產生數據沖突。開源版本的RocketMQ不支持Master宕機，Slave自動切換為Master，阿里云版本的RocketMQ支持自動切換特性。

二、性能（producer生成消息的TPS）

A：Kafka單機寫入TPS約在百萬條/秒，消息大小10個字節

B：RocketMQ單機寫入TPS單實例約7萬條/秒，單機部署3個Broker，可以跑到最高12萬條/秒，消息大小10個字節

備注：Kafka的TPS跑到單機百萬，主要是由于Producer端將多個小消息合并，批量發向Broker。

RocketMQ為什么沒有這么做？

Producer通常使用Java語言，緩存過多消息，GC是個很嚴重的問題

Producer調用發送消息接口，消息未發送到Broker，向業務返回成功，此時Producer宕機，會導致消息丟失，業務出錯

Producer通常為分布式系統，且每臺機器都是多線程發送，我們認為線上的系統單個Producer每秒產生的數據量有限，不可能上萬。

緩存的功能完全可以由上層業務完成。

三、單機支持的隊列數（consumer集群的支持）

Kafka單機超過64個隊列/分區，Load會發生明顯的飆高現象，隊列越多，load越高，發送消息響應時間變長

RocketMQ單機支持最高5萬個隊列，Load不會發生明顯變化

隊列多有什么好處？

單機可以創建更多Topic，因為每個Topic都是由一批隊列組成

Consumer的集群規模和隊列數成正比，隊列越多，Consumer集群可以越大

消息機制

四、消息推送時效性

A：Kafka使用短輪詢方式，實時性取決于輪詢間隔時間

B：RocketMQ使用長輪詢，同Push方式實時性一致，消息的投遞延時通常在幾個毫秒。

五、消息失敗重試機制

A：Kafka消費失敗不支持重試

B：RocketMQ消費失敗支持定時重試，每次重試間隔時間順延

備注：例如充值類應用，當前時刻調用運營商網關，充值失敗，可能是對方壓力過多，稍后在調用就會成功，如支付寶到銀行扣款也是類似需求。

這里的重試需要可靠的重試，即失敗重試的消息不因為Consumer宕機導致丟失。

六、消息推送的順序

A：Kafka支持消息順序，但是一臺Broker宕機后，就會產生消息亂序

B：RocketMQ支持嚴格的消息順序，在順序消息場景下，一臺Broker宕機后，發送消息會失敗，但是不會亂序

Mysql Binlog分發需要嚴格的消息順序

七、消息定時推送策略

A：Kafka不支持定時消息

B：RocketMQ支持兩類定時消息

開源版本RocketMQ僅支持定時Level

阿里云ONS支持定時Level，以及指定的毫秒級別的延時時間

八、分布式事務消息

A：Kafka不支持分布式事務消息

B：阿里云ONS支持分布式定時消息，未來開源版本的RocketMQ也有計劃支持分布式事務消息

九、消息查詢機制

A：Kafka不支持消息查詢

B：RocketMQ支持根據Message Id查詢消息，也支持根據消息內容查詢消息（發送消息時指定一個Message Key，任意字符串，例如指定為訂單Id）

備注：消息查詢對于定位消息丟失問題非常有幫助，例如某個訂單處理失敗，是消息沒收到還是收到處理出錯了。

十、消息回溯

A：Kafka理論上可以按照Offset來回溯消息

B：RocketMQ支持按照時間來回溯消息，精度毫秒，例如從一天之前的某時某分某秒開始重新消費消息

備注：典型業務場景如consumer做訂單分析，但是由于程序邏輯或者依賴的系統發生故障等原因，導致今天消費的消息全部無效，需要重新從昨天零點開始消費，那么以時間為起點的消息重放功能對于業務非常有幫助。

十一、消費并行度

A：Kafka的消費并行度依賴Topic配置的分區數，如分區數為10，那么最多10臺機器來并行消費（每臺機器只能開啟一個線程），或者一臺機器消費（10個線程并行消費）。即消費并行度和分區數一致。

B：RocketMQ消費并行度分兩種情況

順序消費方式并行度同Kafka完全一致

亂序方式并行度取決于Consumer的線程數，如Topic配置10個隊列，10臺機器消費，每臺機器100個線程，那么并行度為1000。

十二、消息軌跡

A：Kafka不支持消息軌跡

B：阿里云ONS支持消息軌跡

十三、Broker端消息過濾

A：Kafka不支持Broker端的消息過濾

B：RocketMQ支持兩種Broker端消息過濾方式

根據Message Tag來過濾，相當于子topic概念

向服務器上傳一段Java代碼，可以對消息做任意形式的過濾，甚至可以做Message Body的過濾拆分。

消息堆積能力

理論上Kafka要比RocketMQ的堆積能力更強，不過RocketMQ單機也可以支持億級的消息堆積能力，我們認為這個堆積能力已經完全可以滿足業務需求。

后期維護

十四、開源社區活躍度

A：Kafka社區更新較慢

B：RocketMQ的github社區有250個個人、公司用戶登記了聯系方式，QQ群超過1000人。

十五、商業支持

A：Kafka原開發團隊成立新公司，目前暫沒有相關產品看到

B：RocketMQ在阿里云上已經開放公測近半年，目前以云服務形式免費供大家商用，并向用戶承諾99.99%的可靠性，同時徹底解決了用戶自己搭建MQ產品的運維復雜性問題

十六、成熟度

A：Kafka在日志領域比較成熟

B：RocketMQ在阿里集團內部有大量的應用在使用，每天都產生海量的消息，并且順利支持了多次天貓雙十一海量消息考驗，是數據削峰填谷的利器。