仓库源文，站点原文

layout: post title: "图解 Raft 共识算法：如何选举领导者？" categories: Raft tags: raft

author: 张乘辉

content {:toc} Raft 是通过以领导者为准实现各个节点日志一致的一种共识算法，被越来越多的分布式系统框架应用，比如 Etcd、Consul 等等，Seata 未来也会引用 Raft，即将发布的 Kafka 2.8 也引入了 Raft，在 Raft 的基础上做了一些改版，在 Kafka 2.8 中称作 KRaft。

由此看来，Raft 是目前大部分分布式系统的首选共识算法，学习 Raft 将有助于你在分布式领域中如鱼得水。

本文主要内容为我对 Raft 选举领导者的一些理解总结。

按照我的理解，Raft 是一种强领导者模型，即一切以领导者为准，实现一系列的共识和各个节点日志一致性的一种共识算法。

Raft 一共有三种成员身份，分别是：领导者（Leader）、跟随者（Follower）、候选人（Candidate）。

跟随者：在 Raft 中只有领导者才会与客户端交互，因此在不发生选举时，跟随者仅默默地处理来自领导者发送的消息，充当数据冗余的作用，当领导者心跳超时，跟随者就会主动推荐自己当选候选人。

候选人：成为候选人之后，就会向其他节点发送请求投票消息，以获取其他节点的投票，如果获得了大多数选票，则当选领导者。

领导者：数据一切以领导者为准，它也是与客户端交互的唯一角色，处理请求，管理日志的复制，同时还不断地发送心跳信息给跟随者，不断刷新跟随者节点的超时时间，以防跟随者发起新的选举。

下面我以一个刚初始化的 Raft 集群为例：

1、初始状态

Raft 每个节点初始化后的心跳超时时间都是随机的，如上所示，节点 C 的超时时间最短（120ms），任期编号都为 0，角色都是跟随者。

2、请求投票

此时没有一个节点是领导者，节点等待心跳超时后，会推荐自己为候选人，向集群其他节点发起请求投票信息，此时任期编号 +1，自荐会获得自己的一票选票。

3、跟随者投票

跟随者收到请求投票信息后，如果该候选人符合投票要求后，则将自己宝贵（因为每个任期内跟随者只能投给先来的候选人一票，后面来的候选人则不能在投票给它了）的一票投给该候选人，同时更新任期编号。

4、当选领导者

当节点 C 赢得大多数选票后，它会成为本次任期的领导者。

5、领导者与跟随者保持心跳

领导者周期性发送心跳消息给其他节点，告知自己是领导者，同时刷新跟随者的超时时间，防止跟随者发起新的领导者选举。

从以上的选举过程看，我们知道在 Raft 中的选举中是有任期机制的，顾名思义，每一任领导者，都有它专属的任期，当领导者更换后，任期也会增加，Raft 中的任期还要注意以下个细节：

如果某个节点，发现自己的任期编号比其他节点小，则会将自己的任期编号更新比自己更大的值；
从上面的选举过程看出，每次推荐自己成为候选人，都会得到自身的那一票；
如果候选人或者领导者发现自己的任期编号比其它节点好要小，则会立即更新自己为跟随者，这点很重要，按照我的理解，这个机制能够解决同一时间内有多个领导者的情况，比如领导者 A 挂了之后，集群其他节点会选举出一个新的领导者 B，在节点 B 恢复之后，会接收来自新领导者的心跳消息，此时节点 A 会立即恢复成跟随者状态；
如果某个节点接收到比自己任期号小的请求，则会拒绝这个请求。

跟随者如果没有在某个时间内接收到来自领导者的心跳，则会发起新一轮的领导者选举，试想一下，如果全部跟随者都在同一时间发起领导者选举，这是一种怎样的场景？会不会造成同一时间内造成选举混乱呢？如果同时发起选举，会不会因为选票被瓜分导致选举失败的原因？

感觉会出现很多问题，但是 Raft 它利用随机超时巧妙地避开了这些问题。为此为我还在视频号录制了一段 Raft 选举过程的视频。

如果你想自己亲自调试并观摩 Raft 选举过程，你可以访问以下网址：