当前位置:   article > 正文

Kafka与RocketMQ的比较_rocketmq和kafka区别

rocketmq和kafka区别

Kafka与RocketMQ是目前比较常用的两种消息中间件。他们有着高吞吐、低延迟的特性,有强大的消息存储能力和堆积处理能力,可以保证消息的可靠性。下面我们从消费模式、消息存储等多方面,比较一下这两个消息队列。

消息消费模式

消息有两种消费模式,推(Push)和拉(Pull)。

Push:producer发送消息后,broker马上把消息投递给consumer。这种方式好在实时性比较高,但是会增加broker的负载;而且消费端能力不同,如果push推送过快,消费端会出现很多问题。服务端需要保存推送状态、保存订阅关系、消费者复杂均衡;push的实时性好,如果消费能力低,导致消费者崩溃或者大量消费丢失

Pull:producer发送消息后,broker什么也不做,等着consumer自己来读取。它的优点在于主动权在消费者端,可控性好;但是间隔时间不好设置,间隔太短浪费资源,间隔太长又会消费不及时。需要保存消息偏移量offset,异常情况下的各种处理,消息处理不及时,容易引起borker堆积

Kafka:Producer采用发送push的方式将消息发到broker上,broker存储后。由Consumer采用pull模式订阅并消费消息。

RocketMQ:基于Pull模式和Push模式的长轮询机制,来平衡Push和Pull模式各自的优缺点。

长轮询:当Consumer过来请求时,broker会保持当前连接一段时间,如果这段时间内有消息到达,则立刻返回给Consumer;这段时间内没有消息的话则返回空然后重新请求。这种方式的缺点就是服务端要保存consumer状态,客户端过多会一直占用资源。

发送端负载均衡

Kafka:指定partition,直接使用;未指定partition但指定key,通过key的hash选出partition;都未指定,轮询选出partition

RocketMQ:消息指定topic、tag、key,无法指定发送到topic的哪个队列,负载均衡采用轮询

消费者负责均衡

Kafka:以partition为最小单位分配。kafka要求同一个consumerGroup中的两个consumer不能消费同一个分区的消息,但可以消费同一topic不同分区的消息;不同consumerGroup中的consumer可以消费同一分区的消息。

RocketMQ:集群模式consumerGroup均分topic中的消息,广播模式每一条消息对会被consumerGroup中的consumer消费一次。消费端多种负载均衡策略:平均、按机房、按配置、一致性hash等

消息存储

Kafka

每个topic可以分为多个partition, 每个partition是一个有序的队列(独立物理文件)。partition中每一条消息都有一个有序的offset(唯一编号)。partition以文件的形式存储在系统中,包含.log 和 .index 分别为存储具体消息和存储log的索引,log文件名为上一个log文件的最后一个offset值+1。根据offset查找消息,二分查找定位索引文件,二分查找找到对应的offset(小于等于指定索引的最大offset)。打开.log文件,定位到position,顺序往下找。

kafka是一个分区一个文件,当topic过多,分区的总量也会增加,kafka中存在过多的文件,当对消息刷盘时,就会出现文件竞争磁盘,出现性能的下降。一个partition(分区)一个文件,顺序读写。一个分区只能被一个消费组中的一个 消费线程进行消费,因此可以同时消费的消费端也比较少。

RocketMQ

CommitLog ,消息存储文件,所有主题的消息都存储在 CommitLog 文件中。一台 Broker服务器 只有一个 CommitLog 文件(组), RocketMQ 会将所有主题的消息存储在同一个文件中,这个文件中就存储着一条条Message,每条Message都会按照顺序写入。

MessageQueue,数据分片机制,MessageQueue 是和 Broker 绑定在一起的,就是说每个 MessageQueue 都可能处于不同的 Broker 机器上,这取决于你的队列数量和Broker集群。既然 MessageQueue 是多个,那么在消息发送的时候,势必要通过某种方式选择一个队列。默认的情况下,就是通过轮询来获取一个消息队列。

ConsumeQueue,一个topic对应一个ConsumeQueue,ConsumerQueue 也是一组组文件。存储消息下CommitLog中的位置,类似索引,类似Kafka中的partition,但只存索引,消息都在CommitLog中

  • 先通过主题名称,可以定位到具体的文件夹;
  • 然后根据消息队列ID找到具体的文件;
  • 最后根据文件内容,找到具体的消息。

每次读取消息时,先读取ConsumeQueue,在通过ConsumeQueue去CommitLog中拿到消息。写消息大量数据IO顺序写到同一个CommitLog‘中,满1G写新的,累计4K强中从pageCache中刷到磁盘。

消息确认

Kafka:发送方ack,接收方:自动或收到提交offset

RocketMQ:发送方:支持同步、异步确认,同步、异步刷盘,接收方:消费者响应

消息重试

Kafka:offset回溯

RocketMQ:死信队列

高可用

Kafka

无状态集群,一个borker一台机器,分区副本会分布在不同服务器上,每台服务器即使master也是slave。producer会将消息发送个对应partition的leader,leader消息写入本地,followers(追随者)从leader拉去消息同步本地并ack,leader收到ack像producer发送ack

RocketMQ

NameServer无主从关系,只做数据冗余。broker有master和slave,master不可用时切换slave,broker与Nameserver所有集群建立长链接。

总结

Kafka:适合吞吐量高的场景,例如日志处理、大数据处理

kafka性吞吐量更高主要是由于Producer端将多个小消息合并,批量发向Broker。kafka采用异步发送的机制,当发送一条消息时,消息并没有发送到broker而是缓存起来,然后直接向业务返回成功,当缓存的消息达到一定数量时再批量发送。

RocketMQ

适合有序场景,并且抗堆积能力强,峰值高的应用也适合。

声明:本文内容由网友自发贡献,不代表【wpsshop博客】立场,版权归原作者所有,本站不承担相应法律责任。如您发现有侵权的内容,请联系我们。转载请注明出处:https://www.wpsshop.cn/w/木道寻08/article/detail/866718
推荐阅读
相关标签
  

闽ICP备14008679号