RocketMQ和Kafka的差异对比

末蓝、 2022-03-12 11:24 317阅读 0赞

## Broker差异 ##

1.  **主从差异**: kafka的master/slave是基于partition维度的，而rocketmq是基于broker维度的；kafka的master/slave是可以切换的，而rocketmq不行，当rocketmq的master宕机时，读能被路由到slave上，但写会被路由到此topic的其他broker上。
2.  **刷盘**： rocketmq支持同步刷盘，也就是每次消息都等刷入磁盘后再返回，保证消息不丢失，但对吞吐量稍有影响。一般在主从结构下，选择异步双写策略是比较可靠的选择。
3.  **消息查询**：rocketmq支持消息查询，除了queue的offset外，还支持自定义key。rocketmq对offset和key都做了索引，均是独立的索引文件。
4.  **消费失败重试与延迟消费**： rocketmq针对每个topic都定义了延迟队列，当消息消费失败时，会发回给broker存入延迟队列中，每个消费者在启动时默认订阅延迟队列，这样消费失败的消息在一段时候后又能够重新消费。延迟时间适合延迟级别一一对应的，延迟时间是随失败次数逐渐增加的，最后一次间隔2小时。当然发送消息是也可以指定延迟级别，这样就能主动设置延迟消费，在一些特定场景下还是有作用的。
5.  **数据写入**： kafka每个partition独占一个目录，每个partition均有各自的数据文件.log；而rocketmq是每个topic共享一个数据文件commitlog因为kafka的topic一般有多个partition，所以kafka的数据写入熟读比rocketmq高出一个量级。但超过一定数量的文件同时写入，会导致原先的顺序写转为随机写，性能急剧下降，所以kafka的分区数量是有限制的。
6.  **服务治理**： kafka用zookeeper来做服务发现和治理，broker和consumer都会向其注册自身信息，同时订阅相应的znode，这样当有broker或者consumer宕机时能立刻感知，做相应的调整；而rocketmq用自定义的nameServer做服务发现和治理，其实时性差点，比如如果broker宕机，producer和consumer不会实时感知到，需要等到下次更新broker集群时(最长30S)才能做相应调整，服务有个不可用的窗口期，但数据不会丢失，且能保证一致性。但是某个consumer宕机，broker会实时反馈给其他consumer，立即触发负载均衡，这样能一定程度上保证消息消费的实时性。

## Producer差异 ##

1.  **发送方式**：kafka默认使用异步发送的形式，有一个memory buffer暂存消息，同时会将多个消息整合成一个数据包发送，这样能提高吞吐量，但对消息的实效有些影响；rocketmq可选择使用同步或者异步发送。
2.  **发送响应**：kafka的发送ack支持三种设置：消息存进memory buffer就返回；等到leader收到消息返回，等到leader和isr的follower都收到消息返回，当然kafka都是异步刷盘。rocketmq都需要等broker的响应确认，有同步刷盘，异步刷盘，同步双写，异步双写等策略，相比于kafka多了一个同步刷盘。

## Consumer差异 ##

1.  **消息过滤**: rocketmq的queue和kafka的partition对应，但rocketmq的topic还能更加细分，可对消息加tag，同时订阅时也可指定特定的tag来对消息做更进一步的过滤。或者向服务器上传一段Java代码，可以对消息做任意形式的过滤，甚至可以做Message Body的过滤拆分。
2.  **有序消息**：rocketmq支持全局有序和局部有序，kafka也支持有序消息，但是如果某个broker宕机了，就不能在保证有序了。
3.  **消费确认**：rocketmq仅支持手动确认，也就是消费完一条消息ack+1，会定期向broker同步消费进度，或者在下一次pull时附带上offset。kafka支持定时确认，拉取到消息自动确认和手动确认，offset存在zookeeper上。
4.  **消费并行度**：kafka的消费者默认是单线程的，一个Consumer可以订阅一个或者多个Partition，一个Partition同一时间只能被一个消费者消费，也就是有多少个Partition就最多有多少个线程同时消费。rocketmq消费者分有序消费模式和并发消费模式，有序模式下，一个消费者也只存在一个线程消费；并发模式下，每次拉取的消息按consumeMessageBatchMaxSize(默认1)拆分后分配给消费者线程池，消费者线程池min=20,max=64。也就是每个queue的并罚度在20-64之间，一个topic有多个queue就相乘。所以rocketmq的并发度比Kafka高出一个量级。
5.  **事务消息**：rocketmq指定一定程度上的事务消息，当前开源版本删除了事务消息回查功能，事务机制稍微变得没有这么可靠了，不过阿里云的rocketmq支持可靠的事务消息；kafka不支持分布式事务消息。
6.  **消费实时性**:kafka是通过短轮训形式拉取消息，消费实时性取决于轮训间隔；rocketmq是通过长连接形式拉取消息，当有新消息时会立即出发拉取，只要消费能力足够，实时性比价可靠