raft算法选举流程详解

引入主节点，通过竞选来获取主节点。节点分为三类：

• 领头结点 Leader
• 从节点 Follower
• 候选节点 Candidate

想象咱们身处一个居民社区里面，这个社区需要选举出一位业委会主任来负责新年的社区大事，Raft 算法会经历如下 3 个阶段。

1）业委会主任选举 —— 领导选举（Leader Election）

• 业委会主任的选举开始了，大家需要从众多热心的业主中选出一位来担任这个角色。
• 就在这时，业主张三挺身而出，他告诉大家：“我愿意担任业委会主任，大家看我行不行”？这就相当于 Raft 算法中的一个节点（Candidate）发起了一次领导选举。
• 随后，张三需要让大家投票支持他。如果在规定的时间内，大多数业主（即节点的多数）都支持张三，那么张三就当选成为了新的业委会主任。这个过程类似于 Raft 算法中通过选票获得多数同意后，成为 领导者（Leader）。

Candidate 发送投票消息给其它所有存活节点，其它节点会对其请求进行回复，如果超过半数的节点回复了竞选请求，那么该 Candidate 就会变成 Leader 节点。

2）管理社区大事 —— 日志复制（Log Replication）

• 当张三当选为业委会主任后，他就要开始负责社区的日常大事了，比如决定花园里要种些什么花，什么时候修缮社区的健身设施。
• 张三会把他的想法写在公告板上，然后请其他业主（即其他节点）照着去做——就像在 Raft 算法中领导者（Leader）把要执行的操作作为日志条目（Log Entry）复制给其它节点。
• 业主们看到公告板的内容后，会按照张三的计划去执行，并把执行的情况反馈给张三。这一过程对应于 Raft 算法中从节点（Follower）接受并应用日志条目，并反馈成功的消息给领导者。

新 Leader 周期性发送心跳包给 Follower，Follower 收到心跳包以后重新计时。这时，Leader 如果接收到了客户端请求，会将数据变更写入日志中，并把数据复制到所有 Follower。

当大多数 Follower 进行修改后，将数据变更操作提交。然后，Leader 会通知所有的 Follower 让它们提交修改，此时所有节点的数据达成一致。

3）主任更替 —— 容错和恢复

• 如果张三因为某些原因突然不能担任业委会主任的职责了，比如他长时间没有发表任何公告或指示，大家就会认为需要再选一个新的业委会主任来接替张三。
• 这时候业主李四站出来，并说：“咱们再来选一次主任吧，我愿意尝试这个角色”。如果李四也得到了大多数业主的支持，那他就会成为新的业委会主任。
• 在这期间，无论主任是张三还是李四，社区的日常运营都要继续，这就要求整个选举过程快速进行，不影响其他社区事务，确保社区管理不受影响。这和 Raft 算法强调系统可用性和稳定性的目的完全一致。

每个 Follower 都会接收 Leader 周期性的心跳，一般为 150~300ms，如果一段时间之后还未收到心跳包，Follower 就变为 Candidate，又开始重复第 1）步。