rmq_vs_kafka

淘寶内部的交易系統使用了淘寶自主研發的notify消息中間件，使用mysql作為消息存儲媒介，可完全水準擴容，為了進一步降低成本，我們認為存儲部分可以進一步優化，2011年初，linkin開源了kafka這個優秀的消息中間件，淘寶中間件團隊在對kafka做過充分review之後，kafka無限消息堆積，高效的持久化速度吸引了我們，但是同時發現這個消息系統主要定位于日志傳輸，對于使用在淘寶交易、訂單、充值等場景下還有諸多特性不滿足，為此我們重新用java語言編寫了rocketmq，定位于非日志的可靠消息傳輸（日志場景也ok），目前rocketmq在阿裡集團被廣泛應用在訂單，交易，充值，流計算，消息推送，日志流式處理，binglog分發等場景。

rocketmq支援異步實時刷盤，同步刷盤，同步複制，異步複制

卡夫卡使用異步刷盤方式，異步複制/同步複制

總結：rocketmq的同步刷盤在單機可靠性上比kafka更高，不會因為作業系統crash，導緻資料丢失。kafka同步replication理論上性能低于rocketmq的同步replication，原因是kafka的資料以分區為機關組織，意味着一個kafka執行個體上會​​有幾百個資料分區，rocketmq一個執行個體上隻有一個資料分區，rocketmq可以充分利用io組commit機制，批量傳輸資料，配置同步replication與異步replication相比，性能損耗約20%~30%，kafka沒有親自測試過，但是個人認為理論上會低于rocketmq。

卡夫卡單機寫入tps約在百萬條/秒，消息大小10個位元組

rocketmq單機寫入tps單執行個體約7萬條/秒，單機部署3個broker，可以跑到最高12萬條/秒，消息大小10個位元組

總結：kafka的tps跑到單機百萬，主要是由于producer端将多個小消息合并，批量發向broker。

rocketmq為什麼沒有這麼做？

制片人通常使用的java語言，緩存過多消息，gc是個很嚴重的問題

producer調用發送消息接口，消息未發送到broker，向業務傳回成功，此時producer當機，會導緻消息丢失，業務出錯

producer通常為分布式系統，且每台機器都是多線程發送，我們認為線上的系統單個producer每秒産生的資料量有限，不可能上萬。

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

單機支援的隊列數

kafka單機超過64個隊列/分區，load會發生明顯的飙高現象，隊列越多，load越高，發送消息響應時間變長。kafka分區數無法過多的問題

rocketmq單機支援最高5萬個隊列，負載不會發生明顯變化

隊列多有什麼好處？

單機可以建立更多話題，因為每個主題都是由一批隊列組成

消費者的叢集規模和隊列數成正比，隊列越多，消費類叢集可以越大

kafka使用短輪詢方式，實時性取決于輪詢間隔時間，0.8以後版本支援長輪詢。

rocketmq使用長輪詢，同push方式實時性一緻，消息的投遞延時通常在幾個毫秒。

消費失敗重試

卡夫卡消費失敗不支援重試。

rocketmq消費失敗支援定時重試，每次重試間隔時間順延

總結：例如充值類應用，目前時刻調用營運商網關，充值失敗，可能是對方壓 力過多，稍後再調用就會成功，如支付寶到銀行扣款也是類似需求。 這裡的重試需要可靠的重試，即失敗重試的消息不因為consumer當機導緻丢失。

卡夫卡支援消息順序，但是一台代理當機後，就會産生消息亂序

rocketmq支援嚴格的消息順序，在順序消息場景下，一台broker當機後，發送消息會失敗，但是不會亂序

mysql的二進制日志分發需要嚴格的消息順序

卡夫卡不支援定時消息

rocketmq支援兩類定時消息

開源版本rocketmq僅支援定時級别，定時級使用者可定制

阿裡雲mq指定的毫秒級别的延時時間

分布式事務消息

卡夫卡不支援分布式事務消息

阿裡雲mq支援分布式事務消息，未來開源版本的rocketmq也有計劃支援分布式事務消息

消息查詢

卡夫卡不支援消息查詢

rocketmq支援根據消息辨別查詢消息，也支援根據消息内容查詢消息（發送消息時指定一個消息密鑰，任意字元串，例如指定為訂單編号）

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

消息回溯

卡夫卡理論上可以按照偏移來回溯消息

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

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

消費并行度

kafka的消費并行度依賴topic配置的分區數，如分區數為10，那麼最多10台機器來并行消費（每台機器隻能開啟一個線程），或者一台機器消費（10個線程并行消費）。即消費并行度和分區數一緻。

rocketmq消費并行度分兩種情況

順序消費方式并行度同卡夫卡完全一緻

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

消息軌迹

卡夫卡不支援消息軌迹

阿裡雲mq支援消息軌迹

開發語言友好性

卡夫卡采用斯卡拉編寫

rocketmq采用的java語言編寫

券商端消息過濾

卡夫卡不支援代理端的消息過濾

rocketmq支援兩種代理端消息過濾方式

根據消息變量來過濾，相當于子主題概念

向伺服器上傳一段java代碼，可以對消息做任意形式的過濾，甚至可以做message身體的過濾拆分。

消息堆積能力

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

開源社群活躍度

卡夫卡社群更新較慢

rocketmq的github的社群有250個個人，公司使用者登記了聯系方式，qq群超過1000人。  mq ###商業支援

卡夫卡原開發團隊成立新公司，目前暫沒有相關産品看到

rocketmq在阿裡雲已經商業化，目前以雲服務形式供大家商用，并向使用者承諾99.99%的可靠性，同時徹底解決了使用者自己搭建mq産品的運維複雜性問題

成熟度

卡夫卡在日志領域比較成熟

rocketmq在阿裡集團内部有大量的應用在使用，每天都産生海量的消息，并且順利支援了多次天貓雙十一海量消息考驗，是資料削峰填谷的利器。