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

數(shù)據(jù)可靠性

• RocketMQ支持異步實時刷盤，同步刷盤，同步復制，異步復制
• 卡夫卡使用異步刷盤方式，異步復制/同步復制

  總結(jié)：RocketMQ的同步刷盤在單機可靠性上比Kafka更高，不會因為操作系統(tǒng)Crash，導致數(shù)據(jù)丟失。Kafka同步Replication理論上性能低于RocketMQ的同步Replication，原因是Kafka的數(shù)據(jù)以分區(qū)為單位組織，意味著一個Kafka實例上會??有幾百個數(shù)據(jù)分區(qū)，RocketMQ一個實例上只有一個數(shù)據(jù)分區(qū)，RocketMQ可以充分利用IO組Commit機制，批量傳輸數(shù)據(jù)，配置同步Replication與異步Replication相比，性能損耗約20%~30%，Kafka沒有親自測試過，但是個人認為理論上會低于RocketMQ。

性能對比

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

  總結(jié)：Kafka的TPS跑到單機百萬，主要是由于Producer端將多個小消息合并，批量發(fā)向Broker。
  RocketMQ為什么沒有這么做？

制片人通常使用的Java語言，緩存過多消息，GC是個很嚴重的問題

Producer調(diào)用發(fā)送消息接口，消息未發(fā)送到Broker，向業(yè)務(wù)返回成功，此時Producer宕機，會導致消息丟失，業(yè)務(wù)出錯

Producer通常為分布式系統(tǒng)，且每臺機器都是多線程發(fā)送，我們認為線上的系統(tǒng)單個Producer每秒產(chǎn)生的數(shù)據(jù)量有限，不可能上萬。

緩存的功能完全可以由上層業(yè)務(wù)完成。
單機支持的隊列數(shù)

• Kafka單機超過64個隊列/分區(qū)，Load會發(fā)生明顯的飆高現(xiàn)象，隊列越多，load越高，發(fā)送消息響應(yīng)時間變長。Kafka分區(qū)數(shù)無法過多的問題
• RocketMQ單機支持最高5萬個隊列，負載不會發(fā)生明顯變化
  隊列多有什么好處？

單機可以創(chuàng)建更多話題，因為每個主題都是由一批隊列組成

消費者的集群規(guī)模和隊列數(shù)成正比，隊列越多，消費類集群可以越大

消息投遞實時性

• Kafka使用短輪詢方式，實時性取決于輪詢間隔時間，0.8以后版本支持長輪詢。

• RocketMQ使用長輪詢，同Push方式實時性一致，消息的投遞延時通常在幾個毫秒。
  消費失敗重試

• 卡夫卡消費失敗不支持重試。

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

  總結(jié)：例如充值類應(yīng)用，當前時刻調(diào)用運營商網(wǎng)關(guān)，充值失敗，可能是對方壓

  力過多，稍后再調(diào)用就會成功，如支付寶到銀行扣款也是類似需求。

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

嚴格的消息順序

• 卡夫卡支持消息順序，但是一臺代理宕機后，就會產(chǎn)生消息亂序
• RocketMQ支持嚴格的消息順序，在順序消息場景下，一臺Broker宕機后，發(fā)送消息會失敗，但是不會亂序

  MySQL的二進制日志分發(fā)需要嚴格的消息順序

定時消息

• 卡夫卡不支持定時消息

• RocketMQ支持兩類定時消息

  • 開源版本RocketMQ僅支持定時級別，定時級用戶可定制
  • 阿里云MQ指定的毫秒級別的延時時間
    分布式事務(wù)消息

• 卡夫卡不支持分布式事務(wù)消息

• 阿里云MQ支持分布式事務(wù)消息，未來開源版本的RocketMQ也有計劃支持分布式事務(wù)消息
  消息查詢

• 卡夫卡不支持消息查詢

• RocketMQ支持根據(jù)消息標識查詢消息，也支持根據(jù)消息內(nèi)容查詢消息（發(fā)送消息時指定一個消息密鑰，任意字符串，例如指定為訂單編號）

  總結(jié)：消息查詢對于定位消息丟失問題非常有幫助，例如某個訂單處理失敗，是消息沒收到還是收到處理出錯了。
  消息回溯

• 卡夫卡理論上可以按照偏移來回溯消息

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

  總結(jié)：典型業(yè)務(wù)場景如consumer做訂單分析，但是由于程序邏輯或者依賴的系統(tǒng)發(fā)生故障等原因，導致今天消費的消息全部無效，需要重新從昨天零點開始消費，那么以時間為起點的消息重放功能對于業(yè)務(wù)非常有幫助。
  消費并行度

?

• Kafka的消費并行度依賴Topic配置的分區(qū)數(shù)，如分區(qū)數(shù)為10，那么最多10臺機器來并行消費（每臺機器只能開啟一個線程），或者一臺機器消費（10個線程并行消費）。即消費并行度和分區(qū)數(shù)一致。

• RocketMQ消費并行度分兩種情況

  • 順序消費方式并行度同卡夫卡完全一致
  • 亂序方式并行度取決于Consumer的線程數(shù)，如Topic配置10個隊列，10臺機器消費，每臺機器100個線程，那么并行度為1000。
    消息軌跡

• 卡夫卡不支持消息軌跡

• 阿里云MQ支持消息軌跡
  開發(fā)語言友好性

• 卡夫卡采用斯卡拉編寫

• RocketMQ采用的Java語言編寫
  券商端消息過濾

• 卡夫卡不支持代理端的消息過濾

• RocketMQ支持兩種代理端消息過濾方式

  • 根據(jù)消息變量來過濾，相當于子主題概念
  • 向服務(wù)器上傳一段Java代碼，可以對消息做任意形式的過濾，甚至可以做Message身體的過濾拆分。
    消息堆積能力

理論上Kafka要比RocketMQ的堆積能力更強，不過RocketMQ單機也可以支持億級的消息堆積能力，我們認為這個堆積能力已經(jīng)完全可以滿足業(yè)務(wù)需求。

開源社區(qū)活躍度

• • 卡夫卡社區(qū)更新較慢
  • RocketMQ的GitHub的社區(qū)有250個個人，公司用戶登記了聯(lián)系方式，QQ群超過1000人。?MQ ###商業(yè)支持
  • 卡夫卡原開發(fā)團隊成立新公司，目前暫沒有相關(guān)產(chǎn)品看到

  • RocketMQ在阿里云已經(jīng)商業(yè)化，目前以云服務(wù)形式供大家商用，并向用戶承諾99.99%的可靠性，同時徹底解決了用戶自己搭建MQ產(chǎn)品的運維復雜性問題
    成熟度

  • 卡夫卡在日志領(lǐng)域比較成熟

  • RocketMQ在阿里集團內(nèi)部有大量的應(yīng)用在使用，每天都產(chǎn)生海量的消息，并且順利支持了多次天貓雙十一海量消息考驗，是數(shù)據(jù)削峰填谷的利器。

轉(zhuǎn)載于:https://www.cnblogs.com/felixzh/p/6197521.html

總結(jié)

以上是生活随笔為你收集整理的RocketMQ与kafka对比（18项差异）-转自阿里中间件的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。