「RocketMQ技术专题」帮你梳理RocketMQ/Kafka的选择理由及二者PK

前提背景

大家都知道，市面上有许多开源的MQ，例如，RocketMQ、Kafka、RabbitMQ等等，现在Pulsar也开始发光，今天我们谈谈笔者最常用的RocketMQ和Kafka，想必大家早就知道二者之间的特点以及区别，但是在实际场景中，二者的选取有可能会范迷惑，那么今天笔者就带领大家分析一下二者之间的区别，以及选取标准吧！

架构对比

RocketMQ的架构

RocketMQ由NameServer、Broker、Consumer、Producer组成，NameServer之间互不通信，Broker会向所有的nameServer注册，通过心跳判断broker是否存活，producer和consumer 通过nameserver就知道broker上有哪些topic。

Kafka的架构

Kafka的元数据信息都是保存在Zookeeper，新版本部分已经存放到了Kafka内部了，由Broker、Zookeeper、Producer、Consumer组成。

Broker对比

主从架构模型差异:

维度不同

• Kafka的master/slave是基于partition(分区)维度的，而RocketMQ是基于Broker维度的；Kafka的master/slave是可以切换的（主要依靠于Zookeeper的主备切换机制）RocketMQ无法实现自动切换，当RocketMQ的Master宕机时，读能被路由到slave上，但写会被路由到此topic的其他Broker上。

刷盘机制

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

消息查询

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

消费失败重试与延迟消费

RocketMQ针对每个topic都定义了延迟队列，当消息消费失败时，会发回给Broker存入延迟队列中，每个消费者在启动时默认订阅延迟队列，这样消费失败的消息在一段时候后又能够重新消费。

• 延迟时间与延迟级别一一对应，延迟时间是随失败次数逐渐增加的，最后一次间隔2小时。
• 当然发送消息是也可以指定延迟级别，这样就能主动设置延迟消费，在一些特定场景下还是有作用的。

数据