2 of the 18 differences between distributed Message Queuing ROCKETMQ and Kafka

In the first 1 articles, I discussed several less rigorous areas of ROCKETMQ and KAKFA. In strict spirit, do not take sides, this article would like to analyze the ROCKETMQ on the basis of Kafka, indeed made a few improvements. If there is something wrong, please correct me.

Interested friends can pay attention to the public number "the way of architecture and technique", get the latest articles.
or scan the following QR code:
The effect of topic/partion quantity on performance

We know that in Kafka, there is a file for each topic_partition. Although each file is sequential IO, but topic or partition too much, the sequential io of each file, performance on disk, or random IO.

So in order to improve this, ROCKETMQ made a significant change in storage, that is, to put all the messages into a file, a single file in the order of writing. topic, partition (in ROCKETMQ, partition is called a queue), here is just a logical division.

About this, Ali middleware team, specifically wrote a blog, testing this. The conclusion is: the number of topic increased to a certain extent, Kafka performance decreased sharply.

http://jm.taobao.org/2016/04/07/kafka-vs-rocketmq-topic-amout/

So for a cluster, Kafka exactly how many partition appropriate, about this, there is an article specifically discussed.

https://www.confluent.io/blog/how-to-choose-the-number-of-topicspartitions-in-a-kafka-cluster/ Kafka Synchronous Brush Disc performance is very low

On this, Ali middleware team, also wrote a blog. The conclusion is: ROCKETMQ's synchronous brush disk performance, is the Kafka 8 times times.

The reasons for this, need to see the source code analysis.

http://jm.taobao.org/2016/04/28/kafka-vs-rocktemq-4/ consumption parallelism

We know that Kafka in order to guarantee the message order of each partition, limit each partition only 1 consumer consumption. For example, your topic has 8 partition, with a maximum of 8 consumer consumption.

ROCKETMQ let go of this restriction, can not guarantee the consumption order, that is, multiple consumer consumption with 1 partition (queue), which will greatly improve the consumption of parallelism.