分布式消息队列RocketMQ与Kafka的18项差异之“拨乱反正“之2

在前1篇，我讨论了RocketMQ与Kakfa的对比中，几个不太严谨的地方。本着严谨的精神，不偏袒任何一方，本篇想分析一下RocketMQ在Kafka的基础上，的确做的几个改进。有不对之处，敬请指正。

本人新书出版，对技术感兴趣的朋友请关注：

https://mp.weixin.qq.com/s/uq2cw2Lgf-s4nPHJ4WH4aw

topic/partion数量对性能的影响

我们知道在Kafka中，是每个topic_partition一个文件。虽然每个文件是顺序IO，但topic或者partition过多，每个文件的顺序IO，表现到磁盘上，还是随机IO。

所以为了改进这个，RocketMQ做了一个存储上的重要改变，就是把所有消息存到一个文件里面，单文件的顺序写。topic、partition(在RocketMQ里面，partition叫做queue），在这里只是一个逻辑上的划分。

关于这个，阿里中间件团队，专门写了一篇博客，测试这个。结论是：topic数量增加到一定程度，kafka性能急剧下降。

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

那么对于一个集群，kafka到底多少个partition合适呢，关于这个，也有一篇文章专门论述。

https://www.confluent.io/blog/how-to-choose-the-number-of-topicspartitions-in-a-kafka-cluster/

Kafka同步刷盘性能很低

关于这个，阿里中间件团队，也写了一篇博客。结论是：RocketMQ的同步刷盘性能，是Kafka的8倍。

关于这个的原因，有待看源码分析。

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

消费并行度

我们知道，Kafka为了保证每个partition的消息顺序，限制每个partition只能1个consumer消费。比如你的topic有8个partition，最多只能有8个consumer消费。

RocketMQ放开了这个限制，可以不保证消费顺序，也即多个consumer消费同1个partition（queue)，这会极大提高消费并行度。