RocketMQ和Kafka的差异对比

版权声明:本文为博主原创文章,未经博主允许不得转载。 https://blog.csdn.net/qq_27529917/article/details/88205400

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高出一个量级。

猜你喜欢

转载自blog.csdn.net/qq_27529917/article/details/88205400