RocketMQ與Kafka對比（18項差別）評價版

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

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

 

爲了方便你們選型，整理一份RocketMQ與Kafka的對比文檔，文中若有錯誤之處，歡迎來函指正。vintage.wang@gmail.com

 

數據可靠性

·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不支持分佈式事務，可是大多互聯網應用採用分佈式事務的不多，主要是由於：一、缺少大規模應用的成功案例

二、死鎖風險，特別是在大併發量下，如今大可能是以客戶端做爲協調者，而客戶端一般部署在虛擬機或者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都很是優秀，不管選擇哪一個都很是不錯，能夠根據自身實力和業務場景靈活取捨。使用開源，若是要想不出錯，研究源碼很是必要。