rocketmq原理源码分析之控制器模式- dledger

简介

     RocketMQ 4.5 版本之前，RocketMQ 的broker是 Master/Slave部署架构，一组 broker 有一个 Master ，有0到若干Slave，Slave复制Master消息存储，随时替代下线的Master。Master/Slave部署架构提供一定的高可用性，但这样的部署架构，主节点下线需要手动进行重启或者手动切换，需要一个新的多副本架构，支持自动切换，解决方案基本可以分为两种：

1. 独立的分布式协调组件，如 zookeeper，实现选主和分布式存储，该方案引入外部组件，增加运维成本。
2. 可嵌入的分布式组件，如 raft ， raft 协议相比前者的优点是不需要引入外部组件，自动选主逻辑集成到各个节点的进程中，节点之间通过通信就可以完成选主。

rocketmq选择 raft，目前有 dledger和jraft两个实现，本文分析dledger控制器，broker是rocketmq的核心组件，负责消息的存储，接收消息，分发消息，dledger控制器提供broker的选主，监管, 元数据保存等服务，保障broker高可用。

本文分分析基于rocketmq 5.2.0，关于dledger原理分析可参看参考资料

关键词

raft/dledger/jraft  dledger/jraft 都是raft实现，其中jraft是蚂蚁金服的作品，改造自百度的braft，代码比较难懂，dledger是openmessage的一个组件，一开始就是java实现，代码相对易读，特性没有jraft丰富

选主/日志复制/状态机  raft特性，可参看参考资料了解

参考资料

https://blog.csdn.net/szlhj/category_12714458.html dledger源码原理分析，包括选主，心跳，日志复制，状态机

dledger

本文分析dledger控制器，本章简单介绍一下dledger

• 应用/client  client是dledger提供给应用访问节点的组件

以下是节点内组件

• rpc服务

rpc服务内置rpc client/rpc server，对外接收外部rpc访问，包括client和节点间通讯；对内，解释rpc请求，转发给Server；对外，发送rpc请求到其他节点

• Server

主程序，负责节点启动，其他组件的启动；写入日志请求初步处理等

• Elector

选举类，负责集群主节点选举

• EntryPusher

日志写入器，内置分发器和处理器，分发器主节点用于复制日志到跟随者；处理器跟随者使用，写入日志

• 存储

存储日志条目，有两个实现，基于内存和基于文件

• 快照/状态机

新版本的dledger提供状态机，dledger成为通用的raft组件，不再是转为rocketmq使用

技术架构

上图dledger控制器模式的技术架构图，只关注dledger控制器与broker部分，dledger控制器集群提供broker选主和分布式存储同步，支撑broker的高可用。

上图的broker指向dledger控制器的蓝色虚线箭头代表broker向控制器的rpc调用，调用分两类，上报和获取，上报数据大部分走raft写， dledger主节点处理，然后复制*1到其他非主节点，过半的dledger worker复制完成，提交日志共识点，同时，所有的dledger节点，包括leader和worker，应用(apply)共识点日志到各自的状态机*2

状态机是dledger应用端的接口，接收已提交的共识日志，在这里，”dledger应用”是控制器，日志是broker上报的信息，控制器的状态机最终汇集日志到ReplicasInfoManager的replicaInfoTable和syncStateSetInfoTable。

*1 关于dledger日志写入和复制原理可参考 dledger原理源码分析系列(四)-日志写入和复制-CSDN博客

*2 关于dledger状态机原理可参考 dledger原理源码分析系列(五)-状态机-CSDN博客

 原理分析

本节分析broker高可用需解决的问题，raft控制器怎样解决

问题

本节分析broker高可用问题

发现broker下线

broker下线，可能是自身崩溃或者网络故障

broker 选主

发现broker master下线，需选出master，在新master的引领下恢复broker组正常

消息存储可用性

broker健康是高可用的基础，但对于slave还不够，slave复制master消息存储，进度过低不可用，需排除；进度跟上，重新加入

解决

上节分析broker高可用需解决的问题，本节分析raft控制器和broker解决问题的方案

下图展示用例，如何保障broker高可用

broker侧：

• broker启动/恢复 无论启动还是恢复，注册到控制器
• 注册 broker注册到控制器，受控制器监管，注册需要获取brokerId，应用brokerId，broker获得标识
• 心跳 定时向控制器发送心跳，控制器记录和处理，这是发现broker下线的关键手段
• 同步broker副本数据  同步副本室心跳的补充，控制器扫描心跳发现broker下线，选举，通知broker选主结果，但通知服务是oneway模式，不保证通知成功，同步broker副本信息，比较自身的master epoch和其他broker的，如果有更新的master epoch，说明自身错过了新master通知，发起选举
• 同步SynStateSet  master定时任务
• 变更为master/slave  控制器选主broker后，通知broker角色变更，master/slave组进入正常工作状态，自动切换完成

控制器侧：

• 扫描心跳 控制器定时扫描broker的心跳，这是发现broker下线的用例
• 选主 不同于dledger的共识选举，broker选主是控制器根据策略选某个broker作为master，不需要多数的3节点及以上

总结：

broker启动或重启恢复，注册到控制器，之后，定时发送心跳到控制器，控制器记录broker心跳，定时扫描心跳记录，未接收到broker 2个周期(可配置)的心跳，认为broker下线，发起broker选主，选主结束通知broker，broker依据选主结果切换为master/slave，实现broker高可用(自动切换)。

   同步broker副本信息 这是心跳的补充，控制器扫描心跳发现broker下线，选举，通知broker选主结果，但通知服务是oneway模式，不保证通知成功，同步broker副本信息，比较自身的master epoch和其他broker的，如果有更新的master epoch，说明自身错过了新master通知

   更新SyncStateSet  broker master负责， master负责复制消息日志到组内slave，拥有slave复制进度的一手资料，不断更新到控制器，为重选master恢复准备

NEXT

下一篇源码分析