Kafka vs RocketMQ

本文对比说明Kafka和RocketMq的区别, 目的:为了说明Kafka为什么比RocketMq快

1. 设计理念

CAP原理

9fd2d05521e043048888da821f43edb4_image.png

CAP原则又称CAP定理，指的是在一个分布式系统中，Consistency（一致性）、 
Availability（可用性）、Partition tolerance（分区容错性），三者不可得兼。

• 一致性（C）：在分布式系统中的所有数据备份，在同一时刻是否同样的值。（等同于所有节点访问同一份最新的数据副本）
• 可用性（A）：在集群中一部分节点故障后，集群整体是否还能响应客户端的读写请求。（对数据更新具备高可用性）
• 分区容忍性（P）：以实际效果而言，分区相当于对通信的时限要求。系统如果不能在时限内达成数据一致性，就意味着发生了分区的情况，必须就当前操作在C和A之间做出选择。

Kafka和RocketMq分别对CAP进行了取舍

• Kafka优先保证了A, 对C进行了降级
• RocketMq优先保证了C, 对A进行了降级

下文分别就各个特性说明

2. 特性对比

2.1 部署结构

Kafka

da6034d7cd88492fad1510f29460b304_image.png

RocketMq

c3148d6425ea430d821340598d2dbf0c_image.png 5f4e9ebe19a74ed6bb19a73e164c7092_image.png

• kafka通过zookeeper来进行协调,具备选举能力 (趋向于高可用性,易维护 )

1. 某个partition的master挂了，该partition对应的某个slave会升级为主对外提供服务
2. 缺陷: 异步Replication下自动选主数据可能丢失

• rocketMq通过自身的namesrv进行协调, 不具备选主能力 (去向于数据一致性, 数据不丢失)

1. Mq只能保证当一个broker挂了，把原本写到这个broker的请求迁移到其他broker上面，而并不是这个broker对应的slave升级为主
2. 维护上没有那么方便

• kafka节点可以同时包含master和slave
• 节点只能是master或slave

2.2 吞吐量

Kafka

97a2971cc8a04c14b45cfb7ed9b017a0_image.png

RocketMq

38bcd565775f4d0fa34b8904c980cdf6_image.png

• kafka partition的数量和对应的物理文件是一一对应的

 1. 这种存储方式， 同一个toptic多文件并发写入, 对于每个文件来说是顺序IO,  吞吐量很高
 2. 但是当并发的读写多个partition的时候，对应多个文件的顺序IO，表现在文件系统的磁盘层面，还是随机IO

• rocketMq采用了单一的日志文件，即把同1台机器上面所有topic的所有queue的消息存放在一个文件里面

 1. 这种方式, 避免了多toptic下随机的磁盘写入
 2. topic数量增多qps不会明显下降

 对于ConsumeQueue，是完全的顺序读写
 对于CommitLog，Producer对其“顺序写”，Consumer却是对其“随机读”

RocketMq CommitLog文件结构

b700ff25db294c50b7067cdce5a8697c_image.png

为了优化Consumer对CommitLog的随机读:

CommitLog进行了结构化设计: CommitLog  -> MappedFileQueue -> MappedFile

其中真正存储数据的是MappedFile。每个文件大小为1G，不满则填充空白,  

MappedFile进行内存映射, 保证高效随机读

吞吐量对比

457895a38ee548798619ace2d253d187_image.png

 在机械硬盘的条件下:  吞吐量对比如上
 
 原因:
 1. kafka的多文件并发写入 VS rocketMq的单文件写入
 2. kafka在producer端做了数据合并，批量发送，性能是rocketmq的十倍（rocketmq没有做这层处理）
     
rocketmq producer端不做缓存的原因:
 1. Producer通常使用Java语言，缓存过多消息，GC是个很严重的问题
 2. Producer调用发送消息接口，消息未发送到Broker，向业务返回成功，此时Producer宕机，会导致消息丢失，业务出错
 3. Producer通常为分布式系统，且每台机器都是多线程发送，我们认为线上的系统单个Producer每秒产生的数据量有限，不可能上万。
 4. 缓存的功能完全可以由上层业务完成

2.3 数据可靠性

rocketmq：支持异步实时刷盘，同步刷盘，同步Replication，异步Replication

kafka：支持异步/同步刷盘，异步/同步Replication，同步下性能极具下降

缺省Kafka是异步刷盘，调用 1次/3秒 fsync

 1. RocketMQ的同步刷盘在单机可靠性上比Kafka更高，不会因为操作系统Crash，导致数据丢失。
 2. 同时同步Replication也比Kafka异步Replication更可靠，数据完全无单点。
 3. Kafka的Replication以topic为单位，支持主机宕机，备机自动切换，但是这里有个问题，由于是异步Replication，那么切换后会有数据丢失，
 4. 同时Leader如果重启后，会与已经存在的Leader产生数据冲突。
 5. 开源版本的RocketMQ不支持Master宕机，Slave自动切换为Master，阿里云版本的支持自动切换特性。

2.4 消息重试机制

kafka: 支持消息发送失败重试机制, 但是只能是固定的重试间隔 (默认尝试3次)

rocketmq: 支持消息发送失败重试机制（可以使用delay定时的尝试发送/接收消息，以及尝试的机会）
 1. exception的情况，一般重复16次 10s、30s、1mins、2mins、3mins等。注意reconsumeTimes这个参数； 
 2. 超时情况，这种情况MQ会无限制的发送给消费端。这种情况就是Consumer端没有返回

2.5 消息顺序性

kafka: consumer只能消费一个partition，来保障顺序写

rocketmq:严格的消息顺序，在顺序消息场景下，一台broker宕机后，发送消息会失败，但是不会乱序


消息重复问题，通过消费方幂等来解决

2.6 分布式事务消息

 分布式事务消息:

 1. Kafka不支持分布式事务消息
 2. RocketMQ阿里云版本支持事务消息, 未来开源版本的RocketMQ也有计划支持分布式事务消息

9ebfdeac52d0494aa76496fe69a445dc_image.png

2.7 消息投递实时性

kafka: 使用短轮询, 实时性取决于轮询间隔时间,  (kafka 0.8版本后支持long pull长轮询)

rocketmq: 使用长轮询，同push方式实时性一致，消息的投递延时通常在几个毫秒

2.8 定时消息

 Kafka不支持定时消息

 RocketMQ支持两类定时消息:
 1. 开源版本RocketMQ仅支持定时Level
 2. 阿里云ONS支持定时Level，以及指定的毫秒级别的延时时间

2.9 消息查询

Kafka不支持消息查询

rocketmq 可以根据messageId查询消息信息

2.10 消息回溯

kafka/rocketmq 都支持offset

RocketMQ支持按照时间来回溯消息，精度毫秒

2.11 消费并行度

kafka 依赖topic配置的分区数，即消费并行度和分区数一致

rocketmq: 
 1. 顺序消费方式并行度同Kafka完全一致
 2. 乱序消费方式并行度取决于consumer的线程数
 （如topic配置10个队列，10台机器消费，每台机器100个线程，那么并行度为1000

2.12 消息堆积能力

理论上Kafka要比RocketMQ的堆积能力更强，不过RocketMQ单机也可以支持亿级的消息堆积能力，
我们认为这个堆积能力已经完全可以满足业务需求。

2.13 consumer负载均衡

kafka:
首先为每个Consumer Group选出了一个Coordinator，所有的Consumer要先找到这个Coordinator，
Coordinator从所有Consumer中，选出了一个Master Consumer，让它负载分配。它分好之后，
把分配结果传给其他的Consumer

rocketmq:
consumer主动上报信息给broker，broker进行收集consumer信息，consumer主动获取broker上
topic的consumer group中所有consumer的列表，每个consumer自己计算对应的
consumerMessageList