? ? ?在互聯(lián)網(wǎng)公司工作的RD們增显，對(duì)消息中間件最為熟悉不過了，如今隨著分布式系統(tǒng)架構(gòu)的盛行涨享。一個(gè)高可用筋搏、高并發(fā)的消息中間件對(duì)我們來說尤為重要。在公司快速增長(zhǎng)時(shí)期厕隧，是沒有精力去研發(fā)這種基礎(chǔ)中間件奔脐。所以如何選擇就成了一個(gè)問題？這個(gè)問題也需要我們深入了解各個(gè)消息中間件的特性栏账。我們就當(dāng)前比較熱門的消息中間件淘寶開源的RocketMQ和linkin開源的kafka做一個(gè)橫向?qū)Ρ忍濉＞突ヂ?lián)網(wǎng)目前應(yīng)用場(chǎng)景劃分。kafka更多的應(yīng)用在日志傳輸上挡爵。但是對(duì)于交易竖般、訂單、充值等對(duì)消息高要求的情況下有諸多特性不滿足茶鹃。淘寶在借鑒kafka的原理的基礎(chǔ)上使用java開發(fā)了RocketMQ（kafka使用scala編程）涣雕。雖然RocketMQ定位于非日志可靠消息傳輸，但對(duì)日志場(chǎng)景也是支持的闭翩。目前阿里集團(tuán)也被廣泛應(yīng)用在訂單挣郭、交易、充值疗韵、流計(jì)算兑障，消息推送，日志流處理，binglog分發(fā)等場(chǎng)景流译。我們從系統(tǒng)性能逞怨、消息機(jī)制、后期維護(hù)三個(gè)大的方面總結(jié)一下福澡。一共16個(gè)特性叠赦。

系統(tǒng)性能

一、 數(shù)據(jù)庫可靠性

A：RocketMQ支持異步刷盤革砸，同步刷盤除秀，同步Replication，異步Replication

B：kafka使用異步刷盤方式算利，異步Replication

備注：RocketMQ的同步刷盤在單機(jī)可靠性上比Kafka更高册踩，不會(huì)因?yàn)椴僮飨到y(tǒng)Crash，導(dǎo)致數(shù)據(jù)丟失效拭。 同時(shí)同步Replication也比Kafka異步Replication更可靠棍好，數(shù)據(jù)完全無單點(diǎn)。另外Kafka的Replication以topic為單位允耿，支持主機(jī)宕機(jī)，備機(jī)自動(dòng)切換扒怖，但是這里有個(gè)問題较锡，由于是異步Replication，那么切換后會(huì)有數(shù)據(jù)丟失盗痒，同時(shí)Leader如果重啟后蚂蕴，會(huì)與已經(jīng)存在的Leader產(chǎn)生數(shù)據(jù)沖突。開源版本的RocketMQ不支持Master宕機(jī)俯邓，Slave自動(dòng)切換為Master骡楼，阿里云版本的RocketMQ支持自動(dòng)切換特性。

二稽鞭、性能（producer生成消息的TPS）

A：Kafka單機(jī)寫入TPS約在百萬條/秒鸟整，消息大小10個(gè)字節(jié)

B：RocketMQ單機(jī)寫入TPS單實(shí)例約7萬條/秒，單機(jī)部署3個(gè)Broker朦蕴，可以跑到最高12萬條/秒篮条，消息大小10個(gè)字節(jié)

備注：Kafka的TPS跑到單機(jī)百萬，主要是由于Producer端將多個(gè)小消息合并吩抓，批量發(fā)向Broker涉茧。

RocketMQ為什么沒有這么做？

Producer通常使用Java語言疹娶，緩存過多消息伴栓，GC是個(gè)很嚴(yán)重的問題

Producer調(diào)用發(fā)送消息接口，消息未發(fā)送到Broker，向業(yè)務(wù)返回成功钳垮，此時(shí)Producer宕機(jī)惑淳，會(huì)導(dǎo)致消息丟失，業(yè)務(wù)出錯(cuò)

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

緩存的功能完全可以由上層業(yè)務(wù)完成倚舀。

三、單機(jī)支持的隊(duì)列數(shù)（consumer集群的支持）

Kafka單機(jī)超過64個(gè)隊(duì)列/分區(qū)忍宋，Load會(huì)發(fā)生明顯的飆高現(xiàn)象痕貌，隊(duì)列越多，load越高糠排，發(fā)送消息響應(yīng)時(shí)間變長(zhǎng)

RocketMQ單機(jī)支持最高5萬個(gè)隊(duì)列舵稠，Load不會(huì)發(fā)生明顯變化

隊(duì)列多有什么好處？

單機(jī)可以創(chuàng)建更多Topic入宦，因?yàn)槊總€(gè)Topic都是由一批隊(duì)列組成

Consumer的集群規(guī)模和隊(duì)列數(shù)成正比哺徊，隊(duì)列越多，Consumer集群可以越大

消息機(jī)制

四乾闰、消息推送時(shí)效性

A：Kafka使用短輪詢方式落追，實(shí)時(shí)性取決于輪詢間隔時(shí)間

B：RocketMQ使用長(zhǎng)輪詢，同Push方式實(shí)時(shí)性一致涯肩，消息的投遞延時(shí)通常在幾個(gè)毫秒轿钠。

五、消息失敗重試機(jī)制

A：Kafka消費(fèi)失敗不支持重試

B：RocketMQ消費(fèi)失敗支持定時(shí)重試病苗，每次重試間隔時(shí)間順延

備注：例如充值類應(yīng)用疗垛，當(dāng)前時(shí)刻調(diào)用運(yùn)營(yíng)商網(wǎng)關(guān)，充值失敗硫朦，可能是對(duì)方壓力過多贷腕，稍后在調(diào)用就會(huì)成功，如支付寶到銀行扣款也是類似需求阵幸。

這里的重試需要可靠的重試花履，即失敗重試的消息不因?yàn)镃onsumer宕機(jī)導(dǎo)致丟失。

六挚赊、消息推送的順序

A：Kafka支持消息順序诡壁，但是一臺(tái)Broker宕機(jī)后，就會(huì)產(chǎn)生消息亂序

B：RocketMQ支持嚴(yán)格的消息順序荠割，在順序消息場(chǎng)景下妹卿，一臺(tái)Broker宕機(jī)后旺矾，發(fā)送消息會(huì)失敗，但是不會(huì)亂序

Mysql Binlog分發(fā)需要嚴(yán)格的消息順序

七夺克、消息定時(shí)推送策略

A：Kafka不支持定時(shí)消息

B：RocketMQ支持兩類定時(shí)消息

開源版本RocketMQ僅支持定時(shí)Level

阿里云ONS支持定時(shí)Level箕宙，以及指定的毫秒級(jí)別的延時(shí)時(shí)間

八、分布式事務(wù)消息

A：Kafka不支持分布式事務(wù)消息

B：阿里云ONS支持分布式定時(shí)消息铺纽，未來開源版本的RocketMQ也有計(jì)劃支持分布式事務(wù)消息

九柬帕、消息查詢機(jī)制

A：Kafka不支持消息查詢

B：RocketMQ支持根據(jù)Message Id查詢消息，也支持根據(jù)消息內(nèi)容查詢消息（發(fā)送消息時(shí)指定一個(gè)Message Key狡门，任意字符串陷寝，例如指定為訂單Id）

備注：消息查詢對(duì)于定位消息丟失問題非常有幫助，例如某個(gè)訂單處理失敗其馏，是消息沒收到還是收到處理出錯(cuò)了凤跑。

十、消息回溯

A：Kafka理論上可以按照Offset來回溯消息

B：RocketMQ支持按照時(shí)間來回溯消息叛复，精度毫秒仔引，例如從一天之前的某時(shí)某分某秒開始重新消費(fèi)消息

備注：典型業(yè)務(wù)場(chǎng)景如consumer做訂單分析，但是由于程序邏輯或者依賴的系統(tǒng)發(fā)生故障等原因褐奥，導(dǎo)致今天消費(fèi)的消息全部無效咖耘，需要重新從昨天零點(diǎn)開始消費(fèi)，那么以時(shí)間為起點(diǎn)的消息重放功能對(duì)于業(yè)務(wù)非常有幫助撬码。

十一鲤看、消費(fèi)并行度

A：Kafka的消費(fèi)并行度依賴Topic配置的分區(qū)數(shù)，如分區(qū)數(shù)為10耍群，那么最多10臺(tái)機(jī)器來并行消費(fèi)（每臺(tái)機(jī)器只能開啟一個(gè)線程），或者一臺(tái)機(jī)器消費(fèi)（10個(gè)線程并行消費(fèi)）找筝。即消費(fèi)并行度和分區(qū)數(shù)一致蹈垢。

B：RocketMQ消費(fèi)并行度分兩種情況

順序消費(fèi)方式并行度同Kafka完全一致

亂序方式并行度取決于Consumer的線程數(shù)，如Topic配置10個(gè)隊(duì)列袖裕，10臺(tái)機(jī)器消費(fèi)曹抬，每臺(tái)機(jī)器100個(gè)線程，那么并行度為1000急鳄。

十二谤民、消息軌跡

A：Kafka不支持消息軌跡

B：阿里云ONS支持消息軌跡

十三、Broker端消息過濾

A：Kafka不支持Broker端的消息過濾

B：RocketMQ支持兩種Broker端消息過濾方式

根據(jù)Message Tag來過濾疾宏，相當(dāng)于子topic概念

向服務(wù)器上傳一段Java代碼张足，可以對(duì)消息做任意形式的過濾，甚至可以做Message Body的過濾拆分坎藐。

消息堆積能力

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

后期維護(hù)

十四碉咆、開源社區(qū)活躍度

A：Kafka社區(qū)更新較慢

B：RocketMQ的github社區(qū)有250個(gè)個(gè)人抖韩、公司用戶登記了聯(lián)系方式，QQ群超過1000人疫铜。

十五茂浮、商業(yè)支持

A：Kafka原開發(fā)團(tuán)隊(duì)成立新公司，目前暫沒有相關(guān)產(chǎn)品看到

B：RocketMQ在阿里云上已經(jīng)開放公測(cè)近半年壳咕，目前以云服務(wù)形式免費(fèi)供大家商用席揽，并向用戶承諾99.99%的可靠性，同時(shí)徹底解決了用戶自己搭建MQ產(chǎn)品的運(yùn)維復(fù)雜性問題

十六囱井、成熟度

A：Kafka在日志領(lǐng)域比較成熟

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