选择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小时。
• 当然发送消息是也可以指定延迟级别，这样就能主动设置延迟消费，在一些特定场景下还是有作用的。

数据读写速度

• Kafka每个partition独占一个目录，每个partition均有各自的数据文件.log，相当于一个topic有多个log文件。
• RocketMQ是每个topic共享一个数据文件commitlog，

Kafka的topic一般有多个partition，所以Kafka的数据写入速度比RocketMQ高出一个量级。

但Kafka的分区数超过一定数量的文件同时写入，