【RocketMQ】RocketMQ 5.0新特性（三）- Controller模式

在RocketMQ 5.0以前，有两种集群部署模式，分别为主从模式（Master-Slave模式）和Dledger模式。

主从模式

主从模式中分为Master和Slave两个角色，集群中可以有多个Master节点，一个Master节点可以有多个Slave节点。Master节点负责接收生产者发送的写入请求，将消息写入CommitLog文件，Slave节点会与Master节点建立连接，从Master节点同步消息数据（有同步复制和异步复制两种方式）。

消费者可以从Master节点拉取消息，也可以从Slave节点拉取消息。

在RocketMQ 4.5版本之前，如果Master宕机，不支持自动将Slave切换为Master，需要人工介入。

Dledger模式

为了解决主从架构下Slave不能自动切换为Master的问题，4.5版本之后提供了DLedger模式，使用Raft算法，如果Master节点出现故障，可以自动从Slave节点中选举出新的Master进行切换。

存在问题

（1）根据Raft算法的多数原则，集群至少有三个节点以上，在消息写入时，也需要大多数的Follower节点响应成功才能认为消息写入成功；

（2）Dledger模式下，进行消息写入的时候，使用的是openmessaging包中提供的接口，无法利用RocketMQ原生的存储和复制能力（比如非Dledger模式下使用暂存池方式写入）；

（3）存在两套日志复制流程（主从模式下一套、Dledger模式下一套），不统一；

主从同步实现原理

Dledger模式下的日志复制

Controller模式

为了解决如上问题，RocketMQ 5.0以后推出了Controller模式，它的特点如下：

（1）在主从部署模式下就具有自动切换Master的能力，5.0之前需要使用DLedger才可以；

（2）可以利用RocketMQ原生存储复制能力，并统一RocketMQ的存储和复制能力；

RocketMQ 5.0对Broker选主相关的功能进行了抽离，放在Controller中，实现了在主从部署模式下就可以自动切换Master，Controller可以独立部署也可以嵌入在NameServer中部署。

独立部署下的Controller：

嵌入NameServer中的部署图如下：

Controller

也称为Controller控制器，一般集群中部署多个Controller，使用Raft算法选举出一个Active DLedger Controller作为主控制器，它主要用来管理一个SyncStateSet集合，

这个集合中存储的是一组跟上Master进度的Broker节点集合，如果Controller发现某个Master Broker下线时，会从集合中选出新的Master Broker并切换，Controller可以单独部署可以嵌在NameServer中部署。

SyncStateSet

SyncStateSet中维护了一个Broker副本组集合，包含当前Master Broker和它的Slave Broker，需要注意在集合内的节点都是跟上Master进度的节点，在节更变动时，由Master Broker向Controller控制器发起变更请求，更新Controller中的SyncStateSet数据，在选举Master的时候，Controller只需从这个列表中选出一个节点成为新的Master即可。

节点变更分为Shrink操作和Expand操作，需要Master Broker发起，它会通过定时任务以及在数据同步过程中判断是否需要进行Shrink或Expand。

Shrink

Shrink指的是将SyncStateSet副本集合中与Master节点差距过大的副本移除，差距的判断条件如下：

节点是否与Master Broker的连接已断，如果断开需要将该节点从SyncStateSet移除；
节点的复制进度是否过大，新增了haMaxTimeSlaveNotCatchup参数，Master Broker会通过定时任务扫描每一个Slave节点的复制信息，里面有每个节点上一次跟上Master进度的时间戳lastCaughtUpTimeMs，如果当前时间减去这个lastCaughtUpTimeMs超过了haMaxTimeSlaveNotCatchup的值，会认为该Slave节点的复制进度过后；

haMaxTimeSlaveNotCatchup：表示Slave没有跟上 Master 的最大时间间隔，若在 SyncStateSet 中的 slave 超过该时间间隔会将其从 SyncStateSet 移除。默认为 15000（15s）。

Expand

如果Master Broker发现某个Slave节点赶上了Master节点的进度，需要将其重新加入到SyncStateSet。

需要注意以上两个操作，都需要Master Broker向Controller节点发送通知，请求更新SyncStateSet中的数据。

选举Master

不管是Controller独立部署，还是嵌入到NameServer中部署，Controller都会监听每个Broker的连接，Broker会定期向Controller发送心跳包，Controller会定时扫描，如果某个Broker心跳包发送超时，会认为这个Broker已经失效，此时会判断Broker是否是Master角色，如果是Master角色就需要从该组的SyncStateSet中重新选出一个节点作为Master。

选举Master的方式比较简单，从该组的SyncStateSet中，挑选一个心跳包发送正常的Slave成为新的Master节点即可，并将结果通知到该组所有的Broker，每个Broker也会定时向Controller发送请求获取主备信息。

Broker端设计

主从架构部署模式下，需要配置brokerRole和brokerId，也就是手动分配Master和Slave，在Controller模式下，这两个参数会失效，不需要再进行配置，角色和ID由Controller来分配。

Controller模式下增加了controllerAddr参数，Broker在启动时，需要配置这个参数，设置每个controller的地址：

controllerAddr：controller的地址，多个controller中间用分号隔开。例如controllerAddr = 127.0.0.1:9877;127.0.0.1:9878;127.0.0.1:9879

Broker上线

Broker配置了每个Controller的地址，Broker启动时，会先向Controller注册，并获取角色关系和brokerId，通过角色关系可以知道自己是Master还是Slave，之后再向NameServer注册。

Broker可以通过任意一个Controller获取Active Controller节点的IP，后台也会有一个定时任务，定时更新Active Controller节点的IP。

主备关系确定

初始化时，第一个Broker在向Controller注册的时候，此时并没有该Broker组的SyncStateSet，所以Active Controller会将第一个向其发送请求共识的Broker设置为Master，之后该组的其他节点会设置为Slave，Master节点的brokerId为0，

Slave节点从1开始编号，往后递增。

由于Controller控制每个节点的角色，所以每个Broker也会定时向Controller发送请求获取主备信息，以便在角色发生变化的时候可以及时更新。

日志复制

MasterEpoch（Epoch）：Master的任期号，与Term类似，每一任Master都会有一个对应的MasterEpoch任期号，这个任期号的值由Controller控制，单独递增；
StartOffset：每一任Master除了有一个任期号之外，还会取当选时对应CommitLog文件中最大的偏移量（MaxPhyOffset），作为本任期期间日志的起始偏移量，记作StartOffset；
EpochFile：用于存放每一任Master对应的日志起始偏移量（<MasterEpoch, StartOffset> 序列），存储在 ~/store文件夹下；

当Broker成为Master时，会进行如下操作：

获取当前CommitLog文件中最后一条消息的偏移量，也就是MaxPhyOffset的值，作为StartOffset；
将当前任期号MasterEpoch和起始偏移量StartOffset的值持久化到EpochFile文件中；
监听Slave节点的连接；

日志复制整体流程

Broker在接收Controller指令之后，会根据Controller的选举结果，转变对应的角色，分别为Master和Slave。

连接阶段

连接阶段用于Master节点与Slave节点间建立连接：

Master节点开始监听连接；
Slave节点请求与Master节点建立连接；

HandShake阶段

Master节点与Slave节点连接建立成功之后，进入HandShake阶段：

Slave节点向Master节点发送HandShake包，里面包含一些状态信息及Slave的地址，数据格式如下：
- Current State：表示当前状态，当前是HandShake阶段，所以表示HandShake；
- Flags：一些标志位；
- SlaveAddressLength：Salve节点的地址长度；
- SlaveAddress：Slave节点的地址，发送给Master节点后，在下个阶段Master节点会判断是否需要将Slave节点加入到SyncStateSet中；
Master节点向Slave节点回复HandShake包，Slave节点收到Master节点回复的包后，会使用本地的Epoch+StartOffset与Master传输的对比，找到截断点进行日志截断，与Master的日志保持一致，Master节点回复的HandShake包数据格式如下：
- Current State：表示当前状态，当前是HandShake阶段；
- Body Size：存储Body的长度；
- Offset：表示当前Master节点的CommitLog最大偏移量；
- Epoch：表示当前Master节点任期号；
- Body：Master端记录的所有任期信息，是一个集合，所以总大小为EpochEntry大小 * EpochEntry条数；

日志截断

endOffset：下一任期的StartOffset，如果没有下一任期，那么取当前CommitLog的最大偏移量作为endOffset；

Slave中将每一任Epoch对应的<Startoffset，Endoffset>序列存储在一个TreeMap中（从大到小排序）：

TreeMap<Epoch, Pair<startOffset,endOffset>> epochMap;

Slave节点会遍历所有的任期（从大到小），然后根据任期号Epoch获取Master节点对应的<startOffset,endOffset>序列进行对比，如果Slave的Epoch与Master一致，并且StartOffset相等，取两者中较小的那个endOffset作为截断位点，之后Slave节点修正自己的<epoch,startoffset>信息，然后进入Transfer阶段进行日志传输。如果未找到截断位点，会一直向后遍历直到找到。

Slave保证在截断位点位置之前的日志与Master一致，之后从截断位点位置开始从Master复制日志。

// Slave从大到小遍历所有的任期

while (iterator.hasNext()) {

    // 任期信息及对应的<startOffset,endOffset>

    Map.Entry<Epoch, Pair<startOffset,endOffset>> curEntry = iterator.next();

    // 根据Epoch任期号获取Master节点对应的<startOffset,endOffset>

    Pair<startOffset,endOffset> masterOffset=findMasterOffsetByEpoch(curEntry.getKey());

    // 如果获取不为空，并且startOffset相等

    if(masterOffset != null &&

            curEntry.getKey().getObejct1() == masterOffset.getObejct1()) {

        // 返回较小的那个endOffset

        truncateOffset = Math.min(curEntry.getKey().getObejct2(), masterOffset.getObejct2());

        break;

   }

}

Transfer阶段

在Transfer阶段，Master节点会不断向Slave发送日志包，开始进行日志复制：

Master节点向Slave节点发送日志包；
Slave节点收到日志包之后，会检测Epoch是否发生变化，然后更新本地的EpochFile，之后向Master节点回复ACK；
Master节点处理Slave节点回复的ACK响应；

参考

RIP-44 Support DLedger Controller

RocketMQ设计思想

RocketMQ官方文档