Ali RocketMQ與Kafka對照

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

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

vintage.wang@gmail.com

數據可靠性

RocketMQ支持異步實時刷盤，同步刷盤。同步Replication，異步Replication
Kafka使用異步刷盤方式。異步Replication

總結：RocketMQ的同步刷盤在單機可靠性上比Kafka更高，不會因爲操做系統Crash，致使數據丟失。

同一時候同步Replication也比Kafka異步Replication更可靠。數據全然無單點。另外Kafka的Replication以topic爲單位，支持主機宕機，備機本身主動切換，但是這裏有個問題，因爲是異步Replication，那麼切換後會有數據丟失。同一時候Leader假設從新啓動後。會與已經存在的Leader產生數據衝突。開源版本號的RocketMQ不支持Master宕機，Slave本身主動切換爲Master，阿里雲版本號的RocketMQ支持本身主動切換特性。

性能對照

Kafka單機寫入TPS約在百萬條/秒，消息大小10個字節
RocketMQ單機寫入TPS單實例約7萬條/秒。單機部署3個Broker。可以跑到最高12萬條/秒，消息大小10個字節

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

RocketMQ爲何沒有這麼作？

Producer一般使用Java語言，緩存過多消息，GC是個很是嚴重的問題
Producer調用發送消息接口，消息未發送到Broker，向業務返回成功，此時Producer宕機，會致使消息丟失。業務出錯
Producer一般爲分佈式系統，且每臺機器都是多線程發送，咱們以爲線上的系統單個Producer每秒產生的數據量有限。不可能上萬。

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

單機支持的隊列數

Kafka單機超過64個隊列/分區。Load會發生明顯的飆高現象，隊列越多。load越高，發送消息響應時間變長
RocketMQ單機支持最高5萬個隊列。Load不會發生明顯變化

隊列多有什麼優勢？

單機可以建立不少其它Topic。因爲每個Topic都是由一批隊列組成
Consumer的集羣規模和隊列數成正比，隊列越多，Consumer集羣可以越大

消息投遞實時性

Kafka使用短輪詢方式，實時性取決於輪詢間隔時間
RocketMQ使用長輪詢，同Push方式實時性一致，消息的投遞延時一般在幾個毫秒。

消費失敗重試

Kafka消費失敗不支持重試
RocketMQ消費失敗支持定時重試，每次重試間隔時間順延

總結：好比充值類應用，當前時刻調用運營商網關。充值失敗，多是對方壓力過多，稍後在調用就會成功，如支付寶到銀行扣款也是相似需求。

這裏的重試需要可靠的重試，即失敗重試的消息不禁於Consumer宕機致使丟失。

嚴格的消息順序

Kafka支持消息順序，但是一臺Broker宕機後。就會產生消息亂序
RocketMQ支持嚴格的消息順序。在順序消息場景下。一臺Broker宕機後。發送消息會失敗。但是不會亂序

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

定時消息

Kafka不支持定時消息
RocketMQ支持兩類定時消息
開源版本號RocketMQ僅支持定時Level
阿里雲ONS支持定時Level，以及指定的毫秒級別的延時時間

分佈式事務消息

Kafka不支持分佈式事務消息
阿里雲ONS支持分佈式定時消息，將來開源版本號的RocketMQ也有計劃支持分佈式事務消息

消息查詢

Kafka不支持消息查詢
RocketMQ支持依據Message Id查詢消息。也支持依據消息內容查詢消息（發送消息時指定一個Message Key，隨意字符串，好比指定爲訂單Id）

總結：消息查詢對於定位消息丟失問題頗有幫助，好比某個訂單處理失敗，是消息沒收到仍是收處處理出錯了。

消息回溯

Kafka理論上可以依照Offset來回溯消息
RocketMQ支持依照時間來回溯消息，精度毫秒。好比從一天以前的某時某分某秒開始又一次消費消息

總結：典型業務場景如consumer作訂單分析。但是由於程序邏輯或者依賴的系統發生問題等緣由，致使今天消費的消息全部無效，需要又一次從昨天零點開始消費，那麼以時間爲起點的消息重放功能對於業務頗有幫助。

消費並行度

Kafka的消費並行度依賴Topic配置的分區數。如分區數爲10。那麼最多10臺機器來並行消費（每臺機器僅僅能開啓一個線程），或者一臺機器消費（10個線程並行消費）。

即消費並行度和分區數一致。

RocketMQ消費並行度分兩種狀況
順序消費方式並行度同Kafka全然一致
亂序方式並行度取決於Consumer的線程數。如Topic配置10個隊列。10臺機器消費，每臺機器100個線程，那麼並行度爲1000。

消息軌跡

Kafka不支持消息軌跡
阿里雲ONS支持消息軌跡

開發語言友好性

Kafka採用Scala編寫
RocketMQ採用Java語言編寫

Broker端消息過濾

Kafka不支持Broker端的消息過濾
RocketMQ支持兩種Broker端消息過濾方式
依據Message Tag來過濾。至關於子topic概念
向server上傳一段Java代碼，可以對消息作隨意形式的過濾，甚至可以作Message Body的過濾拆分。

消息堆積能力

理論上Kafka要比RocketMQ的堆積能力更強。只是RocketMQ單機也可以支持億級的消息堆積能力。咱們以爲這個堆積能力已經全然可以知足業務需求。

開源社區活躍度

Kafka社區更新較慢
RocketMQ的github社區有250個我的、公司用戶登記了聯繫方式。QQ羣超過1000人。 https://github.com/alibaba/RocketMQ/issues/1

商業支持

Kafka原開發團隊成立新公司，眼下暫沒有相關產品看到
RocketMQ在阿里雲上已經開放公測近半年，眼下以雲服務形式免費供你們商用。並向用戶承諾99.99%的可靠性。同一時候完全攻克了用戶本身搭建MQ產品的運維複雜性問題。 http://www.aliyun.com/product/ons

成熟度

Kafka在日誌領域比較成熟
RocketMQ在阿里集團內部有大量的應用在使用。天天都產生海量的消息，並且順利支持了屢次天貓雙十一海量消息考驗。是數據削峯填谷的利器。

轉自【https://github.com/alibaba/RocketMQ/wiki/rmq_vs_kafka】