zoukankan      html  css  js  c++  java
  • 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不支持分布式事务消息。
    ————————————————
    版权声明:本文为CSDN博主「jb_hz」的原创文章,遵循 CC 4.0 BY-SA 版权协议,转载请附上原文出处链接及本声明。
    原文链接:https://blog.csdn.net/qq_27529917/article/details/88205400

  • 相关阅读:
    centos6.5 源码安装 gtk 环境
    世界的复杂性
    将 shell 脚本打包到 rpm 包中
    使用 ipdb 调试 Python
    shell 处理 文件名本身带星号的情况
    如果可以更更完善,为什么不呢?
    比较有名的开源项目
    各种小工具合集
    各种版本对应关系
    dns相关
  • 原文地址:https://www.cnblogs.com/eryun/p/12088253.html
Copyright © 2011-2022 走看看