kafka vs rocketmq 自己总结

简单总结：

rocketmq 设计目的 ：

承载更多～无限制的队列数量 or topic数量， 更低的延迟，更高的消息可靠性

 

从性能角度：

1.简单说同规格集群kafka 吞吐量基本一定更大，但是要求分区量大并且稳定流量、低延时场景下 rocketmq更有优势

 

2.架构层面：

 

主要带宽影响： kafka 1～3副本均匀打散到各个节点上， 一般单节点单副本瓶颈就是 计算单节点带宽 （178MB～1780MB/s）、磁盘读写极限（增强型ssd pl1 350MB/s）， rocketmq master-slave 架构的话，主节点承担读写压力，出方向带宽压力较大，出：入 = 2: 1，即 双副本情况rocketmq流量极限 * 2 = kafka 的流量极限，磁盘层面相同。 而dledger更差，1主 2备，相当于三副本所以 情况rocketmq流量极限 * 3 = kafka 的流量极限

 

软件：rocketmq 当前测试能达到 500MB/s左右（磁盘极限），kafka 只写900MB/s，读写600MB/s

 

延时：

1.rocketmq 延迟更低，毫秒级一般实测 1～10ms，kafka的话基本在百毫秒级，原因：kafka 异步批量发送 有batch.size linger.ms 两个来控制，rocketmq 每条去发送

 

2.kafka 一般都是写入磁盘（1-3 副本），rocketmq可以异步刷盘更快。

 

消息可靠性：

一般认为rocketmq 消息可靠性更强，原因：

 

1.kafka 主要需要依赖用户客户端合理的配置

 

• 客户端发送：同步发送、ack=-1、min.isr = 3(副本数),确保消息发送到 对应分区的isr 列表全都确认就可以不丢失，如果min.isr<副本数，unclean.leader.election.enable = false。消息重试（保证日志打印失败消息等的话可以不用配置太多次，但是处理会更复杂）
• server存储：当某一个节点异常，属于分区leader节点的话，leader节点切换期间写入此分区的消息报错不丢失，follower节点的话误报错无丢失。
• 消费： 依赖自己处理消息后发送ack确认位点。

2.rocketmq 基本不需用户刻意控制

 

• 客户端发送：同步发送，master-slave同步刷盘（测试异步刷盘情况下其实也基本不会丢失，应该是写入速率的限制），消息重试（保证日志打印失败消息等的话可以不用配置太多次，但是处理会更复杂）
• server存储：dledger与kafka结构类似，slave节点异常后不报错不丢失，master节点异常自动切换master，期间消息发送均报错消息不丢失；

master-slave架构 单节点组slave节点异常后不报错不丢失，master节点异常期间消息发送报错 ，需要手动重启重新配置master；多节点组的情况下（topic选择在多节点组上），

 

slave节点异常后不报错消息不丢失，master节点异常期间消息发送不报错，消息会被发送到其他节点组上。

 

• 消费： 依赖自己处理消息后发送ack确认位点。

功能：

1. 消息：rocketmq 提供延时/定时消息、顺序消息等功能（顺序消息实际kafka也可以）
2. rocketmq的权限控制、白名单ip功能 更多；kafka 避免分区不均衡（扩容缩容节点）提供主题重分区功能。rocketmq不存在负载不均衡情况，无需此功能

其他：

1.开发能力强可用rocketmq ，官方文档较差，小bug or feature 较多（例如1. 消费这消费时查看订阅topic，及topic的消费组信息均有缺失只显示当前的 消费，2. 主题设置订阅权限在>1个队列时python客户端可以发送成功 3.acl 权限有漏洞社区已修复， 4.消息类型的topic并不校验）

 

2.消息删除机制，rocketmq默认占用磁盘 80%自动开启删除（可配置）永远写不满，

 

3.rocketmq 架构复杂 4.x，dledger与master-slave 。5.x 引入proxy。

 

4.rocketmq 读消息时候需要在 consumer queue（topic 、队列数、消息位点三层层文件目录）中找到每条消息的对应日志文件MappedFile索引位置，所以消耗cpu较多。消费组多时候对cpu压力也会上升，