rocketMq和kafka的性能對比和原理，Kafka vs RocketMQ Topic數量對單機性能的影響
阿里巴巴中間件團隊對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卻沒有這樣做，主要原因在於：
- 制片人通常使用的Java語言，緩存過多消息，GC是個很嚴重的問題
- Producer調用發送消息接口，消息未發送到Broker，向業務返回成功，此時Producer宕機，會導致消息丟失，業務出錯
- Producer通常為分布式系統，且每台機器都是多線程發送，我們認為線上的系統單個Producer每秒產生的數據量有限，不可能上萬。
- 緩存的功能完全可以由上層業務完成。
但是 當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/