跳到主要内容

三十四、源码分析 RocketMQ DLedger 多副本之 Leader 选主

> 温馨提示：《RocketMQ技术内幕》作者倾力打造的全新专栏：RocketMQ 多副本(主从切换)：
> 1、《RocketMQ 多副本前置篇：初探raft协议》

本文将按照《RocketMQ 多副本前置篇：初探raft协议》的思路来学习RocketMQ选主逻辑。首先先回顾一下关于Leader的一些思考：

1、 节点状态；
需要引入3种节点状态：Follower(跟随者)、Candidate(候选者)，该状态下的节点会发起投票请求，Leader(主节点)。
2、 选举计时器；
Follower、Candidate两个状态时，需要维护一个定时器，每次定时时间从150ms-300ms直接进行随机，即每个节点的定时过期不一样，Follower状态时，定时器到点后，触发一轮投票。节点在收到投票请求、Leader的心跳请求并作出响应后，需要重置定时器。
3、 投票轮次Team；
Candidate状态的节点，每发起一轮投票，Team加一。
4、 投票机制；
每一轮一个节点只能为一个节点投赞成票，例如节点A中维护的轮次为3，并且已经为节点B投了赞成票，如果收到其他节点，投票轮次为3，则会投反对票，如果收到轮次为4的节点，是又可以投赞成票的。
5、 成为Leader的条件；
必须得到集群中初始数量的大多数，例如如果集群中有3台，则必须得到两票，如果其中一台服务器宕机，剩下的两个节点，还能进行选主吗？答案是可以的，因为可以得到2票，超过初始集群中3的一半，所以通常集群中的机器各位尽量为奇数，因为4台的可用性与3台的一样。

> 温馨提示：本文是从源码的角度分析 DLedger 选主实现原理，可能比较鼓噪，文末给出了选主流程图。

本节目录​

  • 1、DLedger关于选主的核心类图
  • 1.1 DLedgerConfig
  • 1.2 MemberState
  • 1.3 raft协议相关
  • 1.3.1 DLedgerClientProtocol