RocketMQ與Kafka對比（18項差異）

2015-02-28 王啟軍 奔跑中的蝸牛

此文是rocketmq作者vintage.wang所寫，對於每項對比，後面都增加了我的觀點，有不對的地方，請各位指出。

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

為了方便大家選型，整理一份RocketMQ與Kafka的對比文件，文中如有錯誤之處，歡迎來函指正。[email protected]

資料可靠性

· RocketMQ支援非同步實時刷盤，同步刷盤，同步Replication，非同步Replication

· Kafka使用非同步刷盤方式，非同步Replication

王啟軍評：這個地方描述有問題，kafka無法設定同步刷盤，但是可以設定同步Replication，使用request.required.acks=-1，所有的replicas 接收才返回ack。

總結：RocketMQ的同步刷盤在單機可靠性上比Kafka更高，不會因為作業系統Crash，導致資料丟失。 同時同步Replication也比Kafka非同步Replication更可靠，資料完全無單點。另外Kafka的Replication以topic為單位，支援主機宕機，備機自動切換，但是這裡有個問題，由於是非同步Replication，那麼切換後會有資料丟失，同時Leader如果重啟後，會與已經存在的Leader產生資料衝突。開源版本的RocketMQ不支援Master宕機，Slave自動切換為Master，

阿里雲版本的RocketMQ支援自動切換特性。

王啟軍評：首先明確第一個問題，就算非同步刷盤，當broker掛掉時，資料是不會丟失的，只有系統crash才會造成丟失，前面指出，雖然kafka是非同步落盤，但是在叢集模式下，可以設定同步replication，如果是同步replication，複製因子為N，允許N-1個服務所在的系統crash，而不會丟失資料，也就不存在切換後的問題。

效能對比

· Kafka單機寫入TPS約在百萬條/秒，訊息大小10個位元組

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

總結：Kafka的TPS跑到單機百萬，主要是由於Producer端將多個小訊息合併，批量發向Broker。

王啟軍評：這個地方kafka也是可以設定是否進行批量傳送的。

RocketMQ為什麼沒有這麼做？

1. Producer通常使用Java語言，快取過多訊息，GC是個很嚴重的問題

2. Producer呼叫傳送訊息介面，訊息未傳送到Broker，向業務返回成功，此時Producer宕機，會導致訊息丟失，業務出錯

3. Producer通常為分散式系統，且每臺機器都是多執行緒傳送，我們認為線上的系統單個Producer每秒產生的資料量有限，不可能上萬。

4. 快取的功能完全可以由上層業務完成。

單機支援的佇列數

· Kafka單機超過64個佇列/分割槽，Load會發生明顯的飆高現象，佇列越多，load越高，傳送訊息響應時間變長

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

佇列多有什麼好處？

1. 單機可以建立更多Topic，因為每個Topic都是由一批佇列組成

2. Consumer的叢集規模和佇列數成正比，佇列越多，Consumer叢集可以越大

訊息投遞實時性

· Kafka使用短輪詢方式，實時性取決於輪詢間隔時間

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

王啟軍評：0.8版本已經有長輪詢實現了

消費失敗重試

· Kafka消費失敗不支援重試

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

王啟軍評：kafka也支援，可以通過下面兩個引數設定

message.send.max.retries=100

retry.backoff.ms=5000

不過這個重試時間是固定的，通常希望有個倍數。訊息不丟失主要依賴ack機制，但是可能會造成重複，這個訊息中介軟體通常希望通過業務來解決，最簡單的辦法，表中設定一個唯一鍵，或者寫業務資料的同時，增加一張日誌表，保證唯一。

總結：例如充值類應用，當前時刻呼叫運營商閘道器，充值失敗，可能是對方壓力過多，稍後在呼叫就會成功，如支付寶到銀行扣款也是類似需求。

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

嚴格的訊息順序

· Kafka支援訊息順序，但是一臺Broker宕機後，就會產生訊息亂序

· RocketMQ支援嚴格的訊息順序，在順序訊息場景下，一臺Broker宕機後，傳送訊息會失敗，但是不會亂序

王啟軍評：不知道這個問題從何而來，不知道具體場景。

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

定時訊息

· Kafka不支援定時訊息

· RocketMQ支援兩類定時訊息

o 開源版本RocketMQ僅支援定時Level

o 阿里雲ONS支援定時Level，以及指定的毫秒級別的延時時間

王啟軍評：此功能還是非常有用的，但是不知道支援的資料數量級有沒有限制

分散式事務訊息

· Kafka不支援分散式事務訊息

· 阿里雲ONS支援分散式定時訊息，未來開源版本的RocketMQ也有計劃支援分散式事務訊息

王啟軍評：雖然kafka不支援分散式事務，但是大多網際網路應用採用分散式事務的很少，主要是因為：1、缺乏大規模應用的成功案例

2、死鎖風險，特別是在大併發量下，現在大多是以客戶端作為協調者，而客戶端通常部署在虛擬機器或者docker這種容器中，一旦掛掉，資料庫只能等客戶端恢復解鎖。

一般使用rocketmq或者kafka的對併發量要求都比較高，使用分散式事務是一個需要考慮的問題。

Kafka有兩個等級的api，大多使用highLevel的，還有一個simple Api，可以自己控制offset的儲存，這樣就可以變向實現分散式事務了。

訊息查詢

· Kafka不支援訊息查詢

· RocketMQ支援根據Message Id查詢訊息，也支援根據訊息內容查詢訊息（傳送訊息時指定一個Message Key，任意字串，例如指定為訂單Id）

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

王啟軍評：此功能非常棒，比較實用。

訊息回溯

· Kafka理論上可以按照Offset來回溯訊息

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

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

消費並行度

· Kafka的消費並行度依賴Topic配置的分割槽數，如分割槽數為10，那麼最多10臺機器來並行消費（每臺機器只能開啟一個執行緒），或者一臺機器消費（10個執行緒並行消費）。即消費並行度和分割槽數一致。

· RocketMQ消費並行度分兩種情況

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

o 亂序方式並行度取決於Consumer的執行緒數，如Topic配置10個佇列，10臺機器消費，每臺機器100個執行緒，那麼並行度為1000。

王啟軍評：這個需要根據具體的業務場景，通常情況下，mq的處理能力已經足夠快，瓶頸通常在業務處理上。

訊息軌跡

· Kafka不支援訊息軌跡

· 阿里雲ONS支援訊息軌跡

開發語言友好性

· Kafka採用Scala編寫

· RocketMQ採用Java語言編寫

Broker端訊息過濾

· Kafka不支援Broker端的訊息過濾

· RocketMQ支援兩種Broker端訊息過濾方式

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

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

王啟軍評：這個功能非常好，實用。

訊息堆積能力

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

開源社群活躍度

· Kafka社群更新較慢

· RocketMQ的github社群有250個個人、公司使用者登記了聯絡方式，QQ群超過1000人。

商業支援

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

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

成熟度

· Kafka在日誌領域比較成熟

· RocketMQ在阿里集團內部有大量的應用在使用，每天都產生海量的訊息，並且順利支援了多次天貓雙十一海量訊息考驗，是資料削峰填谷的利器。

王啟軍評：kafka的確是在日誌領域應用比較廣泛的，新版本逐步開始完善，可靠性方面有了很大提升，但是rocketmq一開始就是以電商為背景的，所以很多功能值得肯定，從長期來看，如果公司有能力的話，應該以rocketmq為基礎，在上面投入人力進行擴充套件研發。短期看rocketmq有待完善，客戶端不夠全，只有java，文件偏少，配置不友好。兩個mq都非常優秀，無論選擇哪個都非常不錯，可以根據自身實力和業務場景靈活取捨。使用開源，如果要想不出錯，研究原始碼非常必要。

更多文章，歡迎微信關注奔跑中的蝸牛，