KAFKA 和 RocketMQ 的不同点

  Kafka RocketMQ 备注
编程语言 Scalar Java  
底层通信模块 JDK NIO Netty  
组件间通信用自定义基于TCP的二进制协议 组件间通信用自定义RemotingCommand协议  
服务管理 zookeeper Nameserver

Nameserver 组件相关数据都放在内存中(kafka存储在磁盘中),无选举机制,Master挂了,只能手动吧 Slave转换成Master

Nameserver  各个实例之间无交互,其他角色同时向多个实例发状态信息

概念 Brocker代表一个服务器的物理机 Brocker是一个逻辑概念,Master Slave代表物理机  
Partition MessageQueue

读队列数量和写队列数量可以不一致:当我们使用updateTopic命令创建topic时,会发现新建的topic下会有默认的8个写对列和8个读对列(依赖于配置),并且读队列的数量和写队列的数量还可以不一致,这是为什么呢?难道在底层读写队列是在物理上分离的吗?抱着这个问题,我分析了相关的源代码,发现底层代码对于读写队列指的都是同一个队列,其中写队列的数量是针对的producer,读队列的数量针对的是consumer:

           a.假设写队列有8个、读队列有4个,那么producer产生的消息会按轮训的方式写入到8个队列中,但是consumer却只能消费前4个队列,只有把读队列重新设置为8后,consumer可以继续消费后4个队列的历史消息;

           b.假设写队列有4个、读队列有8个,那么producer产生的消息会按轮训的方式写入到4个队列中,但是consumer却能消费8个队列,只是后4个队列没有消息可以消费罢了。

数据读写 异步刷盘 同步/异步刷盘  
  异步复制 同步/异步复制  
  Partition leader负责读写,Partition Slave只负责同步 Master负责读写,Slave只能读 如果RocketMQ一个topic只有一个Master,这个Master挂掉后,消息不能够写到服务器
数据存储 topic_patition 文件夹,每个数据文件 对应一个index文件

commitlog:所有topic数据都存入一个commitlog文件中,文件最大1G,追加写

comsumequeue:commitlog的索引,主要存messagequeue 对应的 offset,供commumer消费使用

indexfile:索引文件 可以通过key查找到所有包含这个key的message,主要用于数据搜索

 
producer发送数据方式 同步/异步 同步/异步/oneway  
消费模式

多个Consumer放在同一个Group(集群)

多个Consumer每一个放单独的Group(广播)

扫描二维码关注公众号,回复: 12497234 查看本文章
Consumer都放到一个Group里面,通过设置参数来确定是 广播 还是集群模式  
  pull模式 push/pull 模式 RocketMQ push 实际是轮询的pull
Consumer Offset 提交策略

1、自动提交(poll()方法中提交,判断距上次提交是否超过5s,超过就提交,提交最新获取到的offset。所以部分数据可能还没有消费)

2、手动提交(参数可指定分区和特定offset)

(1)同步提交

(2)异步提交

 
Rebalance机制 Consumer Leader 统一计算好后,发给服务器,然后服务器再下发给所有Consumer 每一个Consumer单独计算,彼此不知道对方的计算结果 RocketMQ在某些特殊情况下(Master挂掉的同事,Comsumer有变动) 会出现 一个MessageQueue被多个Comsumer消费的情况
Rebalance策略

1、Range(默认)(每个topic单独计算,如果订阅的topic比较多,会造成比较严重的分配不均)

2、RoundRobin:消费组内所有消费者以及消费者所订阅的所有topic拉通全量计算,可以解决以上问题

  • AllocateMessageQueueAveragely:平均分配(默认)

  • AllocateMessageQueueAveragelyByCircle:循环分配

  • AllocateMessageQueueConsistentHash:一致性哈希

  • AllocateMessageQueueByConfig:根据配置进行分配

  • AllocateMessageQueueByMachineRoom:根据机房

  • AllocateMachineRoomNearby:就近分配

 
数据可靠性

某些情况下能实现

Exactly Once

只能实现

at least Once

kafka:producer在同一个会话中 会有seq number计数,来保证发送端的幂等性。

RocketMQ在producer发送不成功后有重试,可能发送重复数据

猜你喜欢

转载自blog.csdn.net/weixin_42226343/article/details/104237392