分布式消息队列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),这会极大提高消费并行度。

©️2020 CSDN 皮肤主题: 编程工作室 设计师:CSDN官方博客 返回首页