Outline
In fact, always wanted to write a rocketMq and kafka differences in architecture, but it has been a problem not understood so that is why no hands, inadvertently heard people today demand a bit seems to understand this issue, so there is this Compared.
This blog is mainly about two different points clear of kafka and rocketMq, 1, rocketMq of namesvr and kafka the zookeeper contrast; 2, kafka Why have greater throughput than rocketMq. If you can clear the above two issues I think have been very satisfied.
Finally, with reference to the article which has introduced some good links, we are interested can take a look at, but in fact in some places than I explain more in-depth.
namesrv VS zk
1, we can compare the differences and rocketMq kafka on the selected coordinator node, kafka ZooKeeper be coordinated through, and coordinated by its own rocketMq namesrv.
2, Kafka equipped election function, Kafka inside, Master / Slave election, has two steps: Step 1, first of all the machine, to elect a KafkaController by ZK; Step 2, and then by the Controller, the decision per a partition of the Master who is, who Slave Yes. Because of the electoral function, so kafka master a partition hung up, a slave of the corresponding partition will be upgraded based external services.
3, rocketMQ do not have the role election, Master / Slave is also fixed. When a Master hung up, you can write to Master on the other, but can not make a switch to Slave Master. So rocketMq is how to achieve high availability it is actually very simple, the role of all broker nodes rocketMq are the same, topic and corresponding queue number assigned above is the same, Mq can only be guaranteed when a broker hung up, the the broker was originally written request to migrate to other broker above, rather than the corresponding slave broker upgrade based.
4, rocketMq coordinator node appears in the design of more lightweight, use another way to solve the availability problem, the idea is you can learn from.
About Throughput
1, first described below a few pictures from the Internet to share , that is behind me refer to the article listed in the article inside.
2, kafka created in the message storage process based on the number of topic and partition of the physical file, which means that we create a topic and specify the three partition, then there will be three physical files directory, will talk about the number of partition and the corresponding physical file is one to one.
3, rocketMq message storage on a logistics issue, also said the legendary commitLog, the number of rocketMq queue is in fact consumeQueue which reflects, in fact, only one physical file commitLog real messages are stored.
4, multi-file write VS rocketMq kafka concurrent single-file write, the performance difference can be imagined kafka win.
5, kafka of a large number of file storage will lead to a problem, it said in a particularly large number of partition when disk access is a big bottleneck will occur, after all, a single file is looked at append operation, but will inevitably lead among multiple files seek disk.
Reference article
Topic influence of Kafka vs RocketMQ-- number of stand-alone performance
Author: Sunny brother _374
link: https: //www.jianshu.com/p/c474ca9f9430
Source: Jane book
Jane book copyright reserved by the authors, are reproduced in any form, please contact the author to obtain authorization and indicate the source.