RocketMQ原理—5.高可用+高并发+高性能架构

大纲

1.RocketMQ的整体架构与运行流程

2.基于NameServer管理Broker集群的架构

3.Broker集群的主从复制架构

4.基于Topic和Queue实现的数据分片架构

5.Broker基于Pull模式的主从复制原理

6.Broker层面到底如何做到数据0丢失

7.数据0丢失与写入高并发的取舍

8.RocketMQ读写分离主从漂移设计

9.RocketMQ为什么采取惰性读写分离模式

10.Broker数据与服务是否都实现高可用了

11.Broker数据与服务的数据一致性设计

12.Broker基于Raft协议的主从架构设计

13.Raft协议的Leader选举算法介绍

14.Broker基于状态机实现的Leader选举

15.Broker基于DLedger的数据写入流程

16.Broker引入DLedger后的存储兼容设计

17.Broker主从节点之间的元数据同步

18.Broker基于Raft协议的主从切换机制

19.Consumer端队列负载均衡分配机制

20.Consumer消息拉取的挂起机制分析

21.Consumer的处理队列与并发消费

22.Consumer处理成功后的消费进度管理

23.Consumer消息重复消费原理剖析

24.Consumer处理失败时的延迟消费机制

25.ConsumerGroup变动时的重平衡机制

1.RocketMQ的整体架构与运行流程

2.基于NameServer管理Broker集群的架构

3.Broker集群的主从复制架构

4.基于Topic和Queue实现的数据分片架构

5.Broker基于Pull模式的主从复制原理

(1)Broker主从复制的Push模式和Pull模式

(2)Broker基于Pull模式的主从复制原理

(3)Push消费模式 vs Pull消费模式

(1)Broker主从复制的Push模式和Pull模式

Push同步模式：Producer往Broker主节点写入数据后，Broker主节点会主动把数据推送Push到Broker从节点里。

Pull同步模式：Producer往Broker主节点写入数据后，Broker主节点会等待从节点发送拉取数据的Pull请求。Broker主节点收到从节点的拉取数据请求后，才会把数据发送给从节点。

其实，Broker发送消息给Consumer进行消费，同样也是有两种模式：Push模式和Pull模式。

Push消费模式：就是Broker会主动把消息发送给消费者，消费者是被动接收Broker推送过来的消息，然后进行处理。

Pull消费模式：就是Broker不会主动推送消息给消费者，而是消费者主动发送请求到Broker去拉取消息，然后进行处理。

(2)Broker基于Pull模式的主从复制原理

Broker主节点在启动后，会监听来自从节点的连接请求。Broker从节点在启动后，会主动向主节点发起连接请求。

首先，当Broker主节点和从节点建立好网络连接后，各自会初始化一些组件。Broker主节点会创建并初始化一个HAConnection组件，专门用于处理从节点的同步请求。Broker从节点会创建并初始化两个组件，一个是HAClient主从同步请求线程、一个是HAClient主从同步响应线程。

然后，Broker从节点的HAClient主从同步请求线程，会不断发送主从同步请求，到主节点的HAConnection组件，期间会带上从节点向主节点已拉取的最大的物理偏移量max offset。

接着，主节点的HAConnection组件便会到磁盘文件取出最大物理偏移量max offset之后的数据，然后返回给从节点。

之后，从节点的HAClient主从同步响应线程便会对收到的这些max offset之后的数据进行处理，写入到其磁盘文件中。

(3)Push消费模式 vs Pull消费模式

一个消费者组内的多台机器会分别负责一部分MessageQueue的消费。那么每台机器就必须要连接到对应的Broker，尝试消费里面的MessageQueue对应的消息。此时就涉及到两种消费模式了：Push消费模式和Pull消费模式。

实际上，这两个消费模式本质是一样的，都是消费者机器主动发送请求到Broker机器去拉取一批消息来处理。Push消费模式底层是基于Pull消费模式来实现的，只不过它的名字叫做Push而已。意思是Broker会尽可能实时的把新消息交给消费者机器来进行处理，它的消息时效性会更好。

一般使用RocketMQ时，消费模式通常选择Push模式，因为Pull模式的代码写起来更加复杂和繁琐，而且Push模式底层本身就是基于消息拉取的方式来实现的，只不过时效性更好而已。

Push模式的实现思路：当消费者发送请求到Broker去拉取消息时，如果有新的消息可以消费就马上返回一批消息到消费机器去处理，处理完之后会接着立刻发送请求到Broker机器去拉取下一批消息。

所以消费者在Push模式下处理完一批消息，会马上发起请求拉取下一批消息。消息处理的时效性非常好，看起来就像Broker一直不停地推送消息给消费者一样。

此外，Push模式下有一个请求挂起和长轮询机制。当拉取消息的请求发送到Broker，结果发现没有新的消息给处理时，就会让请求线程挂起，默认是挂起15秒。然后这个期间Broker会有后台线程每隔一会儿就去检查一下是否有新的消息。另外在这个挂起过程中，如果有新的消息到达了会主动唤醒挂起的线程，然后把消息返回给消费者。

当然消费者进行消息拉取的底层源码是比较复杂的，涉及大量细节，但核心思路大致如此。需要注意：哪怕是常用的Push消费模式，本质也是消费者不停地发送请求到Broker去拉取一批一批的消息。

6.Broker层面到底如何做到数据0丢失

第一种场景：Broker主节点JVM进程崩溃 ==> 数据在PageCache，即便异步刷盘也不影响。

第二种场景：Broker主节点服务器崩溃 ==> 数据在PageCache，异步刷盘会丢失，同步刷盘不丢失。

第三种场景：Broker主节点服务器硬盘坏掉 ==> 如果Broker从节点数据还没同步最新的，就会丢失。

Broker要做到数据0丢失，需要同步刷盘 + 同步复制。也就是Producer向Broker主节点写数据时，Broker主节点返回写入成功响应的前提是：主节点落盘成功 +