淘寶內部的交易系統使用了淘寶自主研發的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。

效能對比

• RocketMQ單機寫入TPS單例項約7萬條/秒，單機部署3個Broker，可以跑到最高12萬條/秒，訊息大小10個位元組

  總結：Kafka的TPS跑到單機百萬，主要是由於Producer端將多個小訊息合併，批量發向Broker。
  RocketMQ為什麼沒有這麼做？

1. 製片人通常使用的Java語言，快取過多訊息，GC是個很嚴重的問題
2. Producer呼叫傳送訊息介面，訊息未傳送到Broker，向業務返回成功，此時Producer宕機，會導致訊息丟失，業務出錯
3. Producer通常為分散式系統，且每臺機器都是多執行緒傳送，我們認為線上的系統單個Producer每秒產生的資料量有限，不可能上萬。
4. 快取的功能完全可以由上層業務完成。
   單機支援的佇列數

• Kafka單機超過64個佇列/分割槽，Load會發生明顯的飆高現象，佇列越多，load越高，傳送訊息響應時間變長。Kafka分割槽數無法過多的問題
• RocketMQ單機支援最高5萬個佇列，負載不會發生明顯變化
  佇列多有什麼好處？

1. 單機可以建立更多話題，因為每個主題都是由一批佇列組成
2. 消費者的叢集規模和佇列數成正比，佇列越多，消費類叢集可以越大

訊息投遞實時性

• 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單機也可以支援億級的訊息堆積能力，我們認為這個堆積能力已經完全可以滿足業務需求。

開源社群活躍度