Raft

大家好，我是 Rustin。最近在做 6.824 的实验 lab2，今天想写一篇文章记录一下前段时间做的 Raft 领导人选举机制的实现。 此博客在 GitHub 上公开发布. 如果您有任何问题或疑问，请在此处打开一个 issue。 简介 6.824 是 MIT 的分布式系统公开课，今年还有官方的视频资料放出。 目前也有国内的同学正在进行翻译工作，可以参考一下。 课程质量非常高，国内也有一些整理好的相关资料可以参考。 下面我就简单描述一下 Raft 领导人选举机制实现过程和一些踩过的坑，我会尽可能的聚焦在实现实验的细节上，因为我可能对 Raft 目前的理解也比较浅显。所以如果您对这篇文章感兴趣，请您先阅读论文和观看课程视频并尝试实现。 领导人选举规则分析 在 Raft 中分别有三种角色分别是：Leader, Follower 和 Candidate。在整个系统正常运行过程中，只会有一个 Leader 节点，其他的都是 Follower 节点。只有在需要重新选举的阶段，节点会尝试将自己转换为 Candidate，然后向所有的节点发出投票 RPC 消息展开选举。 我觉得而一个比较好的切入思路就是搞明白何时需要进行 Leader 的选举？我们阅读论文会发现主要有两种情况需要进行选举，一种就是当 Raft 集群启动之后开始第一次选举，另外一种就是 Leader 出现故障，无法使用心跳机制维持自己的统治， 导致选举超时机制触发，节点开始尝试新的一轮的选举(需要注意的是，选举有可能在一个 Term 中没有结果，那么就在下个 Term 中继续选举直到选出 Leader)。 搞清楚何时进行选举，我们再来看看选举的 RPC 请求和回复的数据结构： Request 参数 解释 term 候选人的任期号 candidateId 请求选票的候选人的 Id lastLogIndex 候选人的最后日志条目的索引值 lastLogTerm 候选人最后日志条目的任期号 Reply 返回值 解释 term 当前任期号，以便于候选人去更新自己的任期号 voteGranted 候选人赢得了此张选票时为真 从数据结构中我们可以看到能够影响到选举的主要有两个部分，一个是 Term，另外一个就是候选人的最后一条日志条目。那我们就尝试从这两点方面去消化和理解选举的规则：...