rocketMq和kafka的性能對比和原理

根據阿里巴巴中間件團隊對rocketMq，kafka和rabbitMq的發送消息性能的測試，在單機同步發送的場景下，Kafka>RocketMQ>RabbitMQ。以下圖：

Kafka的吞吐量高達17.3w/s，

RocketMQ吞吐量在11.6w/s

RabbitMQ的吞吐量5.95w/s，CPU資源消耗較高。它支持AMQP協議，實現很是重量級，爲了保證消息的可靠性在吞吐量上作了取捨。

爲何kafka和rocketMq性能如此高呢，詳見如下文章：https://blog.csdn.net/z69183787/article/details/80323581

https://www.cnblogs.com/cai-cai777/p/10212907.html

kafka和rocketMq都使用順序io寫磁盤和零複製。而Kafka的TPS跑到單機百萬，rocketMQ單機寫入TPS單實例約7萬條/秒，單機部署3個Broker，能夠跑到最高12萬條/秒，消息大小10個字節。

kafka性能如此之高主要是因爲Producer端將多個小消息合併，批量發向Broker：

kafka採用異步發送的機制，當發送一條消息時，消息並無發送到broker而是緩存起來，而後直接向業務返回成功，當緩存的消息達到必定數量時再批量發送。此時減小了網絡io，從而提升了消息發送的性能，可是若是消息發送者宕機，會致使消息丟失，業務出錯，因此理論上kafka利用此機制提升了io性能卻下降了可靠性。
RocketMQ卻沒有這樣作，主要緣由在於：

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

可是 當broker裏面的topic的partition數量過多時，kafka的性能卻不如rocketMq，是由於kafka和rocketMq在存儲機制上的不一樣。

kafka和rocketMq都使用文件存儲，可是，kafka是一個分區一個文件，當topic過多，分區的總量也會增長，kafka中存在過多的文件，當對消息刷盤時，就會出現文件競爭磁盤，出現性能的降低。

一個partition（分區）一個文件，順序讀寫。這樣帶來的影響是，一個分區只能被一個消費組中的一個 消費線程進行消費，所以能夠同時消費的消費端也比較少。

而rocketMq中，全部的隊列都存儲在一個文件中，每一個隊列的存儲的消息量也比較小，所以topic的增長對rocketMq的性能的影響較小。也從而rocketMq能夠存在的topic比較多，能夠適應比較複雜的業務。

全部的隊列存儲一個文件（commitlog）中，因此rocketmq是順序寫io，隨機讀。每次讀消息時先讀邏輯隊列consumQue中的元數據，再從commitlog中找到消息體。增長了開銷。

 

資料來源：http://jm.taobao.org/2016/04/07/kafka-vs-rocketmq-topic-amout/