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

本文簡單分析一下產(chǎn)生這種問題的原因及因此產(chǎn)生的其他問題。

Rocket MQ的存儲結(jié)構(gòu)

RocketMQ的存儲結(jié)構(gòu)如下：

RocketMQ在同一個broker上， 所有topic（及topic的queue）的數(shù)據(jù)都存儲在同一個文件中（CommitLog），對每個queue有獨立的文件（ConsumeQueue）記錄queue相關(guān)的數(shù)據(jù)在commit中的位置，一般ConsumeQueue都可在內(nèi)存中緩存。

Kafka的存儲結(jié)構(gòu)

Kafka的存儲結(jié)構(gòu)如下：

Kafka的存儲是每個機器上topic的partition（Rocketmq中的queue）的數(shù)據(jù)獨立存儲：每個partition對應(yīng)自己的數(shù)據(jù)文件。

差異對比

1. 性能差異

這種存儲上的差別導(dǎo)致如果單臺機器上的partition（queue）數(shù)量太多， 對RocketMq來講， 數(shù)據(jù)存儲的IO可以合并并寫到同一個文件， 因此性能不會下降太多。 但對Kafka，隨著partition的增多， 會發(fā)生多個文件同時IO的情況， 如果這些文件在同一個磁盤上， 就會引起IO寫競爭， 因此性能會大幅下降?？赏ㄟ^將partition分散在不同磁盤環(huán)境這種競爭。

一般一個broker會由多個topic共享， 因此這種差異可作為選擇消息系統(tǒng)的一個重要參考。

2. 同構(gòu)系統(tǒng)和異構(gòu)系統(tǒng)的區(qū)別

同構(gòu)系統(tǒng)和異構(gòu)系統(tǒng)的區(qū)別如下：

同構(gòu)系統(tǒng)：

主從機器上的內(nèi)容完全一樣

主從間數(shù)據(jù)復(fù)制的效率高

異構(gòu)系統(tǒng)：

異構(gòu)系統(tǒng)各個機器上的內(nèi)容不同

充分利用各個機器的資源， 每臺機器都可作為寫機器（目前絕大多數(shù)系統(tǒng)都是僅主可寫）從RocketMQ和Kafka的架構(gòu)上可知， RocketMQ是同構(gòu)系統(tǒng)， Kafka是異構(gòu)系統(tǒng)， RocketMQ不可能是異步系統(tǒng)， 因為對同一個queue， 其offset在主從上需要保持一致。3. topic設(shè)置差別因為RocketMQ的數(shù)據(jù)在同一個文件， 因此設(shè)置只能是broker維度的設(shè)置， 不能精細(xì)到topic級別， 比如： 數(shù)據(jù)存儲時間， 刷盤策略， 主從同步策略等。

Kafka支持topic級別的設(shè)定，靈活性上Kafka更好。

其他

MQ使用

在應(yīng)用中， 如果能使用MQ的場景個人比較傾向于使用MQ， 因為本身引入MQ的技術(shù)和運維成本并不高，并能解決可靠性和數(shù)據(jù)分布式問題。

2. MQ的選擇

主要根據(jù)業(yè)務(wù)場景， 但如果業(yè)務(wù)場景沒有明顯特點， 個人傾向選擇RocketMQ， 主要兩點理由：

RocketMQ的功能更豐富： 延遲隊列， 基于key的消息查詢， 事務(wù)，tag過濾等。

RocketMQ的客戶端更友好： 提供了基于process queue的方式處理了多線程問題（這里碰到很多實現(xiàn)誤區(qū)是自實現(xiàn)多線程， 處理不好容易丟失數(shù)據(jù)）。

當(dāng)然Kafka也有其自身優(yōu)勢， 比如客戶端支持更豐富， 社區(qū)更成熟， 流處理支持更好等。
責(zé)任編輯人：CC