RocketMQ 和 Kafka 的差异对比

Broker 差异

主从差异: kafka 的 master/slave 是基于 partition 维度的，而 rocketmq 是基于 broker 维度的；kafka 的 master/slave 是可以切换的，而 rocketmq 不行，当 rocketmq 的 master 宕机时，读能被路由到 slave 上，但写会被路由到此 topic 的其他 broker 上。

刷盘： rocketmq 支持同步刷盘，也就是每次消息都等刷入磁盘后再返回，保证消息不丢失，但对吞吐量稍有影响。一般在主从结构下，选择异步双写策略是比较可靠的选择。

消息查询：rocketmq 支持消息查询，除了 queue 的 offset 外，还支持自定义 key。rocketmq 对 offset 和 key 都做了索引，均是独立的索引文件。

消费失败重试与延迟消费： rocketmq 针对每个 topic 都定义了延迟队列，当消息消费失败时，会发回给 broker 存入延迟队列中，每个消费者在启动时默认订阅延迟队列，这样消费失败的消息在一段时候后又能够重新消费。延迟时间适合延迟级别一一对应的，延迟时间是随失败次数逐渐增加的，最后一次间隔 2 小时。

当然发送消息是也可以指定延迟级别，这样就能主动设置延迟消费，在一些特定场景下还是有作用的。

数据写入： kafka 每个 partition 独占一个目录，每个 partition 均有各自的数据文件.log；而 rocketmq 是每个 topic 共享一个数据文件 commitlog 因为 kafka 的 topic 一般有多个 partition，所以 kafka 的数据写入熟读比 rocketmq 高出一个量级。但超过一定数量的文件同时写入，会导致原先的顺序写转为随机写，性能急剧下降，所以 kafka 的分区数量是有限制的。

服务治理： kafka 用 zookeeper 来做服务发现和治理，broker 和 consumer 都会向其注册自身信息，同时订阅相应的 znode，这样当有 broker 或者 consumer 宕机时能立刻感知，做相应的调整；而 rocketmq 用自定义的 nameServer 做服务发现和治理，其实时性差点，比如如果 broker 宕机，producer 和 consumer 不会实时感知到，需要等到下次更新 broker 集群时(最长 30S)才能做相应调整，服务有个不可用的窗口期，但数据不会丢失，且能保证一致性。但是某个 consumer 宕机，broker 会实时反馈给其他 consumer，立即触发负载均衡，这样能一定程度上保证消息消费的实时性。

Producer 差异

发送方式：kafka 默认使用异步发送的形式，有一个 memory buffer 暂存消息，大数据培训同时会将多个消息整合成一个数据包发送，这样能提高吞吐量，但对消息的实效有些影响；rocketmq 可选择使用同步或者异步发送。

发送响应：kafka 的发送 ack 支持三种设置：消息存进 memory buffer 就返回；等到 leader 收到消息返回，等到 leader 和 isr 的 follower 都收到消息返回，当然 kafka 都是异步刷盘。rocketmq 都需要等 broker 的响应确认，有同步刷盘，异步刷盘，同步双写，异步双写等策略，相比于 kafka 多了一个同步刷盘。

Consumer 差异

消息过滤: rocketmq 的 queue 和 kafka 的 partition 对应，但 rocketmq 的 topic 还能更加细分，可对消息加 tag，同时订阅时也可指定特定的 tag 来对消息做更进一步的过滤。或者向服务器上传一段 Java 代码，可以对消息做任意形式的过滤，甚至可以做 Message Body 的过滤拆分。

有序消息：rocketmq 支持全局有序和局部有序，kafka 也支持有序消息，但是如果某个 broker 宕机了，就不能在保证有序了。

消费确认：rocketmq 仅支持手动确认，也就是消费完一条消息 ack+1，会定期向 broker 同步消费进度，或者在下一次 pull 时附带上 offset。kafka 支持定时确认，拉取到消息自动确认和手动确认，offset 存在 zookeeper 上。

消费并行度：kafka 的消费者默认是单线程的，一个 Consumer 可以订阅一个或者多个 Partition，一个 Partition 同一时间只能被一个消费者消费，也就是有多少个 Partition 就最多有多少个线程同时消费。

rocketmq 消费者分有序消费模式和并发消费模式，有序模式下，一个消费者也只存在一个线程消费；并发模式下，每次拉取的消息按 consumeMessageBatchMaxSize(默认 1)拆分后分配给消费者线程池，消费者线程池 min=20,max=64。也就是每个 queue 的并罚度在 20-64 之间，一个 topic 有多个 queue 就相乘。所以 rocketmq 的并发度比 Kafka 高出一个量级。

事务消息：rocketmq 指定一定程度上的事务消息，当前开源版本删除了事务消息回查功能，事务机制稍微变得没有这么可靠了，不过阿里云的 rocketmq 支持可靠的事务消息；kafka 不支持分布式事务消息。消费实时性:kafka 是通过短轮训形式拉取消息，消费实时性取决于轮训间隔；rocketmq 是通过长连接形式拉取消息，当有新消息时会立即出发拉取，只要消费能力足够，实时性比价可靠

作者：尚硅谷

链接：https://juejin.cn/post/7041803968179077134

来源：稀土掘金

著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。