淘寶內部的交易系統使用了淘寶自主研發的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在阿里集團內部有大量的應用在使用，每天都產生海量的消息，並且順利支持了多次天貓雙十一海量消息考驗，是數據削峯填谷的利器。