本文對比說明Kafka和RocketMq的區(qū)別, 目的:為了說明Kafka為什么比RocketMq快

1. 設(shè)計理念

CAP原理

9fd2d05521e043048888da821f43edb4_image.png

CAP原則又稱CAP定理，指的是在一個分布式系統(tǒng)中，Consistency（一致性）、 
Availability（可用性）、Partition tolerance（分區(qū)容錯性），三者不可得兼。

• 一致性（C）：在分布式系統(tǒng)中的所有數(shù)據(jù)備份，在同一時刻是否同樣的值。（等同于所有節(jié)點(diǎn)訪問同一份最新的數(shù)據(jù)副本）
• 可用性（A）：在集群中一部分節(jié)點(diǎn)故障后，集群整體是否還能響應(yīng)客戶端的讀寫請求。（對數(shù)據(jù)更新具備高可用性）
• 分區(qū)容忍性（P）：以實(shí)際效果而言，分區(qū)相當(dāng)于對通信的時限要求。系統(tǒng)如果不能在時限內(nèi)達(dá)成數(shù)據(jù)一致性，就意味著發(fā)生了分區(qū)的情況，必須就當(dāng)前操作在C和A之間做出選擇。

Kafka和RocketMq分別對CAP進(jìn)行了取舍

• Kafka優(yōu)先保證了A, 對C進(jìn)行了降級
• RocketMq優(yōu)先保證了C, 對A進(jìn)行了降級

下文分別就各個特性說明

2. 特性對比

2.1 部署結(jié)構(gòu)

Kafka

da6034d7cd88492fad1510f29460b304_image.png

RocketMq

c3148d6425ea430d821340598d2dbf0c_image.png

5f4e9ebe19a74ed6bb19a73e164c7092_image.png

• kafka通過zookeeper來進(jìn)行協(xié)調(diào),具備選舉能力 (趨向于高可用性,易維護(hù) )

1. 某個partition的master掛了，該partition對應(yīng)的某個slave會升級為主對外提供服務(wù)
2. 缺陷: 異步Replication下自動選主數(shù)據(jù)可能丟失

• rocketMq通過自身的namesrv進(jìn)行協(xié)調(diào), 不具備選主能力 (去向于數(shù)據(jù)一致性, 數(shù)據(jù)不丟失)

1. Mq只能保證當(dāng)一個broker掛了，把原本寫到這個broker的請求遷移到其他broker上面，而并不是這個broker對應(yīng)的slave升級為主
2. 維護(hù)上沒有那么方便

• kafka節(jié)點(diǎn)可以同時包含master和slave
• 節(jié)點(diǎn)只能是master或slave

2.2 吞吐量

Kafka

97a2971cc8a04c14b45cfb7ed9b017a0_image.png

RocketMq

38bcd565775f4d0fa34b8904c980cdf6_image.png

• kafka partition的數(shù)量和對應(yīng)的物理文件是一一對應(yīng)的

 1. 這種存儲方式， 同一個toptic多文件并發(fā)寫入, 對于每個文件來說是順序IO,  吞吐量很高
 2. 但是當(dāng)并發(fā)的讀寫多個partition的時候，對應(yīng)多個文件的順序IO，表現(xiàn)在文件系統(tǒng)的磁盤層面，還是隨機(jī)IO

• rocketMq采用了單一的日志文件，即把同1臺機(jī)器上面所有topic的所有queue的消息存放在一個文件里面

 1. 這種方式, 避免了多toptic下隨機(jī)的磁盤寫入
 2. topic數(shù)量增多qps不會明顯下降

 對于ConsumeQueue，是完全的順序讀寫
 對于CommitLog，Producer對其“順序?qū)憽?，Consumer卻是對其“隨機(jī)讀”

RocketMq CommitLog文件結(jié)構(gòu)

b700ff25db294c50b7067cdce5a8697c_image.png

為了優(yōu)化Consumer對CommitLog的隨機(jī)讀:

CommitLog進(jìn)行了結(jié)構(gòu)化設(shè)計: CommitLog  -> MappedFileQueue -> MappedFile

其中真正存儲數(shù)據(jù)的是MappedFile。每個文件大小為1G，不滿則填充空白,  

MappedFile進(jìn)行內(nèi)存映射, 保證高效隨機(jī)讀

吞吐量對比

457895a38ee548798619ace2d253d187_image.png

 在機(jī)械硬盤的條件下:  吞吐量對比如上
 
 原因:
 1. kafka的多文件并發(fā)寫入 VS rocketMq的單文件寫入
 2. kafka在producer端做了數(shù)據(jù)合并，批量發(fā)送，性能是rocketmq的十倍（rocketmq沒有做這層處理）
     
rocketmq producer端不做緩存的原因:
 1. Producer通常使用Java語言，緩存過多消息，GC是個很嚴(yán)重的問題
 2. Producer調(diào)用發(fā)送消息接口，消息未發(fā)送到Broker，向業(yè)務(wù)返回成功，此時Producer宕機(jī)，會導(dǎo)致消息丟失，業(yè)務(wù)出錯
 3. Producer通常為分布式系統(tǒng)，且每臺機(jī)器都是多線程發(fā)送，我們認(rèn)為線上的系統(tǒng)單個Producer每秒產(chǎn)生的數(shù)據(jù)量有限，不可能上萬。
 4. 緩存的功能完全可以由上層業(yè)務(wù)完成

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

rocketmq：支持異步實(shí)時刷盤，同步刷盤，同步Replication，異步Replication

kafka：支持異步/同步刷盤，異步/同步Replication，同步下性能極具下降

缺省Kafka是異步刷盤，調(diào)用 1次/3秒 fsync

 1. RocketMQ的同步刷盤在單機(jī)可靠性上比Kafka更高，不會因?yàn)椴僮飨到y(tǒng)Crash，導(dǎo)致數(shù)據(jù)丟失。
 2. 同時同步Replication也比Kafka異步Replication更可靠，數(shù)據(jù)完全無單點(diǎn)。
 3. Kafka的Replication以topic為單位，支持主機(jī)宕機(jī)，備機(jī)自動切換，但是這里有個問題，由于是異步Replication，那么切換后會有數(shù)據(jù)丟失，
 4. 同時Leader如果重啟后，會與已經(jīng)存在的Leader產(chǎn)生數(shù)據(jù)沖突。
 5. 開源版本的RocketMQ不支持Master宕機(jī)，Slave自動切換為Master，阿里云版本的支持自動切換特性。

2.4 消息重試機(jī)制

kafka: 支持消息發(fā)送失敗重試機(jī)制, 但是只能是固定的重試間隔 (默認(rèn)嘗試3次)

rocketmq: 支持消息發(fā)送失敗重試機(jī)制（可以使用delay定時的嘗試發(fā)送/接收消息，以及嘗試的機(jī)會）
 1. exception的情況，一般重復(fù)16次 10s、30s、1mins、2mins、3mins等。注意reconsumeTimes這個參數(shù)； 
 2. 超時情況，這種情況MQ會無限制的發(fā)送給消費(fèi)端。這種情況就是Consumer端沒有返回

2.5 消息順序性

kafka: consumer只能消費(fèi)一個partition，來保障順序?qū)?
rocketmq:嚴(yán)格的消息順序，在順序消息場景下，一臺broker宕機(jī)后，發(fā)送消息會失敗，但是不會亂序


消息重復(fù)問題，通過消費(fèi)方冪等來解決

2.6 分布式事務(wù)消息

 分布式事務(wù)消息:

 1. Kafka不支持分布式事務(wù)消息
 2. RocketMQ阿里云版本支持事務(wù)消息, 未來開源版本的RocketMQ也有計劃支持分布式事務(wù)消息

9ebfdeac52d0494aa76496fe69a445dc_image.png

2.7 消息投遞實(shí)時性

kafka: 使用短輪詢, 實(shí)時性取決于輪詢間隔時間,  (kafka 0.8版本后支持long pull長輪詢)

rocketmq: 使用長輪詢，同push方式實(shí)時性一致，消息的投遞延時通常在幾個毫秒

2.8 定時消息

 Kafka不支持定時消息

 RocketMQ支持兩類定時消息:
 1. 開源版本RocketMQ僅支持定時Level
 2. 阿里云ONS支持定時Level，以及指定的毫秒級別的延時時間

2.9 消息查詢

Kafka不支持消息查詢

rocketmq 可以根據(jù)messageId查詢消息信息

2.10 消息回溯

kafka/rocketmq 都支持offset

RocketMQ支持按照時間來回溯消息，精度毫秒

2.11 消費(fèi)并行度

kafka 依賴topic配置的分區(qū)數(shù)，即消費(fèi)并行度和分區(qū)數(shù)一致

rocketmq: 
 1. 順序消費(fèi)方式并行度同Kafka完全一致
 2. 亂序消費(fèi)方式并行度取決于consumer的線程數(shù)
 （如topic配置10個隊(duì)列，10臺機(jī)器消費(fèi)，每臺機(jī)器100個線程，那么并行度為1000

2.12 消息堆積能力

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

2.13 consumer負(fù)載均衡

kafka:
首先為每個Consumer Group選出了一個Coordinator，所有的Consumer要先找到這個Coordinator，
Coordinator從所有Consumer中，選出了一個Master Consumer，讓它負(fù)載分配。它分好之后，
把分配結(jié)果傳給其他的Consumer

rocketmq:
consumer主動上報信息給broker，broker進(jìn)行收集consumer信息，consumer主動獲取broker上
topic的consumer group中所有consumer的列表，每個consumer自己計算對應(yīng)的
consumerMessageList