RocketMq核心原理总结

RocketMq相关概念

重要模块和参数

NameServer : 提供轻量级的Broker路由服务。

RocketMQ是一个保持最终一致性的架构设计，它架构决定了它只需要一个轻量级的元数据服务器就足够了，而不需要像Zookeeper这样的强一致性解决方案。不依赖另一个中间件，从而减少整体维护成本

Broker：实际处理消息存储、转发等服务的核心组件。
Producer：消息生产者集群。通常是业务系统中的一个功能模块。
Consumer：消息消费者集群。通常也是业务系统中的一个功能模块。
Topic：消息主题，属于逻辑概念，根据topic对消息进行归类。
Message Queue：属于物理概念，相当于kafka中Topic的分区；用于并行发送和接收消息。
 

特点

1、适合多topic的场景
2、集群消费模式下, 相同Consumer Group的每个Consumer实例平均分摊消息。
3、广播消费模式下，相同Consumer Group的每个Consumer实例都接收全量的消息
4、基于Netty的实现远程通信功能，如NameServer和broker，broker和客户端之间，以及各个broker之间交互都是基于netty来实现的。
5、使用长轮询机制，避免浪费网络带宽以及服务器的性能。

长轮询机制
当Broker接收到Consumer的Pull请求时，判断如果没有对应的消息，不用直接给Consumer响应，而是就将这个Pull请求给缓存起来。当Producer发送消息过来时，增加一个步骤去检查是否有对应的已缓存的Pull请求，如果有，就及时将请求从缓存中拉取出来，并将消息通知给Consumer。

实现原理

1、Broker在启动的时候向所有的NameServer注册，并保持长连接，每30s发送一次心跳
2、Producer在发送消息的时候从NameServer获取Broker服务器地址，根据负载均衡算法选择一台服务器来发送消息
3、Conusmer消费消息的时候同样从NameServer获取Broker地址，然后主动拉取消息来消费
 

消息类型

顺序消息：将消息发送到同一个队列MessageQueue来实现的。
广播消息：把消息发给了所有订阅了对应主题的消费者，而不管消费者是不是同一个消费者组。
延迟消息：支持18个固定的延迟级别，会先把消息存入Schedule_Topic主题中对应的队列。然后等延迟时间到了，再转发到目标队列，推送给消费者进行消费。
批量消息：将多条消息合并成一个批量消息，一次发送出去。这样的好处是可以减少网络IO，提升吞吐量。并且这批消息应该有相同的Topic。
事务消息：保证了发送者本地事务和发送消息的原子性，事务消息机制的关键是在发送消息时，会将消息转为一个half半消息，并存入RocketMQ内部的一个 RMQ_SYS_TRANS_HALF_TOPIC 这个Topic，这样对消费者是不可见的。再经过一系列事务检查通过后，再将消息转存到目标Topic，这样对消费者就可见了。

half消息流程：
1、生产者发生half消息给Mq，此时消息是在一个half队列中的
2、Mq回复half消息
3、生产者执行本地事务
4、返回本地事务状态
 a、若成功commit，则进行提交，即将消息从half队列中转到正常队列中
 b、若失败rollback，则进行回滚，将消息丢弃
 c、若状态未知unKnown，则会定时回查生产者本地事务状态

 

集群模式

普通集群

master负责响应客户端的请求，并存储消息。slave则只负责对master的消息进行同步保存，并响应部分客户端的读请求。消息同步方式分为同步同步和异步同步。各个节点的角色无法进行切换，master节点挂了会导致集群不可用。

数据同步方式
SYNC_MASTER同步复制：消息写入 master 后， master会等待slave同步数据成功后才向 producer 返回成功 ACK。
ASYNC_MASTER异步复制：消息写入 master 后，master立即向producer返回成功 ACK ，无需等待 slave 同步数据成功。
 

Dledger高可用集群

集群会选出一个节点作为leader，而当leader节点挂了后，会从follower中自动选出一个节点升级成为leader。
leader选举：raft协议进行选举
数据同步流程：采用raft协议的两阶段提交
1、leader收到写入数据请求后，标记为uncommitted状态，然后将数据发送给follower节点
2、follower节点收到uncommitted状态的消息后，给leader返回ack
3、leader收到半数以上ack后，把消息标记为committed状态，并写入commitlog文件
4、leader发送committed状态的消息给follower，follower将消息更新为committed状态，并写入commitlog文件

raft协议leader选举和数据同步参考：https://blog.csdn.net/VivianStark/article/details/126804401

 

刷盘机制

SYNC_FLUSH同步刷盘：消息写入broker内存pageCache，并通过fsync持久化到 broker 的磁盘后才算是消息写入成功，吞吐量会下降，但是消息更安全。
ASYNC_FLUSH异步刷盘：消息写入broker内存pageCache就表示消息写入成功，吞吐量较大，但是消息可能丢失。

存储文件

commit Log消息存储文件

存储消息的元数据。所有消息都会顺序存入到CommitLog文件当中。CommitLog由多个文件组成，每个文件固定大小1G。以第一条消息的offset偏移量为文件名。
CommitLog文件存储所有消息实体。不区分topic和message queue，所有生产者发过来的消息，都会依次顺序写入到Commitlog文件当中。这样的好处是可以减少查找目标文件的时间，让消息以最快的速度落盘。
对比Kafka存文件时，需要寻找消息所属的Partition文件，再完成写入，当Topic比较多时，这样的Partition寻址就会浪费比较多的时间，所以Kafka不太适合多Topic的场景。

IndexFile

主要是辅助消息检索，为了消息查询提供了一种通过MeessageId或者MessageKey以及时间区间来检索文件方法。存储了MessageKey的hash值，时间戳、以及消息在CommitLog中的offset偏移量。

ConsumerQueue

一个MessageQueue一个文件，记录当前MessageQueue被哪些消费者组消费到了哪一条CommitLog
minOffset：开始的偏移量，maxOffset：当前已写入最大的偏移量，consumerOffset：消费者当前消费到的偏移量。由此可见从consumerOffset到maxOffset是消费者还未消费的消息。
 

消息写入流程

1、producer根据规则选出一个MessageQueue
 1.1、指定了MessageQueue，则直接使用
 1.2、未指定MessageQueue，使用轮询（通过消息索引自增取模）选出一个 MessageQueue
2、producer发送消息到该MessageQueue所属broker，若该broker不是leader节点，则将消息转给leader节点处理
3、leader将消息标记为uncommitted状态，并同步给follower
4、follower节点收到uncommitted状态的消息后，给leader返回ack
5、leader收到半数以上ack后，把消息标记为committed状态，并写入本地commitlog文件
6、leader发送committed状态的消息给follower，follower将消息更新为committed状态，并写入本地commitlog文件
 

消息删除机制

对于非当前写的文件（该文件已经写入完成）如果超过了一定的保留时间（可以配置），不管消息是否被消费，这些文件都会被认为是过期文件，通过定时任务定时删除。

默认情况下，Broker会启动后台线程，每60秒，检查CommitLog、ConsumeQueue文件。然后对超过72小时的数据进行删除。

 

Consumer负载均衡

因为广播模式所有的Consumer都会收到全量消息，所以RocketMQ的负载均衡只针对于Consumer集群消费的模式；每次分配时，都会将MessageQueue和消费者ID进行排序后，再用不同的分配算法将MessageQueue分配给消费者。

触发条件

1、消费组里的consumer增加或减少了
2、给topic增加了MessageQueue

分配策略

默认采用平均分配策略
1、AllocateMessageQueueAveragely：平均分配。将所有MessageQueue平均分给每一个消费者
2、AllocateMessageQueueAveragelyByCircle：轮询分配。轮流的给一个消费者分配一个MessageQueue
3、AllocateMachineRoomNearby：将同机房的Consumer和Broker优先分配在一起
4、AllocateMessageQueueConsistentHash：一致性hash算法
 

rocketmq的Pull和Push区别

1、 pull表示消费者主动拉取，可以批量拉取，也可以单条拉取，所以pull可以由消费者自己控制，根据自己的消息处理能力来进行控制，但是消费者不能及时知道是否有消息，可能会拉到的消息为空，针对这个问题通过长轮询机制解决。

2、push是一种定时的Pull机制
 

rocketmq高性能原因

1、磁盘顺序读写：每次都是将消息顺序写入commitlog中
2、数据传输的零拷贝：通过操作系统的sendfile来实现
3、CommitLog文件不区分topic和message queue存储，让消息以最快的速度落盘

延迟消息实现原理

1、broker服务启动时，针对18个延迟级别，各启动一个轮训任务，每隔1s执行一次，将消息符合的消息从延迟队列移动到目标队列
2、broker收到延迟消息后，修改Topic和Queue为延迟队列（Topic为固定的SCHEDULE_TOPIC_XXXX，Queue则为延迟级别减1），将原来的Topic和Queue放到事务属性中，并落盘到commitLog文件中
3、broker轮训任务遍历到延迟时间到了，就会将消息再转发到目标队列，将消息写入commitlog并推送给消费者

事务消息实现原理

1、producer发送消息时，指定事务监听类，half消息发送成功后会调用该监听方法
2、producer消息属性设置事务消息标识，并发送消息
3、producer消息发送成功后，执行本地事务（本地监听方法），执行完后设置事务状态（提交、回滚、未知），并给broker发送事务状态。
4、broker收到事务消息后，将Topic和Queue替换成RMQ_SYS_TRANS_HALF_TOPIC和0，并将原来的Topic和Queue放到事务属性中，并落盘到commitLog文件中，并给producer返回发送状态
5、broker收到事务状态后，如果是提交，通过请求头的偏移量从commitlog中取出半消息，然后将事务半消息的主题和队列还原，将消息投递到原本的主题的队列中，并移除half消息（实际是迁移到另一个队列中）。如果是回滚，则直接移除half消息。
6、broker 60s后还未收到事务状态的响应，则会发起主动回查（默认6一次，查15次），获取half主题的所有队列，进行遍历处理

零拷贝参考：https://blog.csdn.net/VivianStark/article/details/126810235