服务器角色转换图
1.1 跟随者当服务器程序启动时，他们都是跟随者身份。
1.2 一个跟随者服务器节点只要他从领导人或者候选者处接收到有效的 RPCs，就将继续保持着跟随者状态。
1.3 领导者周期性的向所有跟随者发送心跳包（即不包含日志项内容的附加日志项 RPCs）来维持自己的权威。
1.4 如果一个跟随者在一段时间里没有接收到任何消息，也就是选举超时，那么他就会认为系统中没有可用的领导者，并发起选举以选出新的领导者。
2.1 要开始一次选举过程，跟随者先要增加自己的当前任期号并且转换到候选人状态。
2.2 然后他会并行的向集群中的其他服务器节点发送请求投票的 RPCs 来给自己投票。候选人会继续保持着当前状态直到以下三件事情之一发生：
(a) 他自己赢得了这次的选举
(b) 其他的服务器成为领导者
(c) 一段时间之后没有任何一个获胜的人。
3.1 当一个候选人从整个集群的大多数服务器节点获得了针对同一个任期号的选票，那么他就赢得了这次选举并成为领导人
3.2 每一个服务器最多会对一个任期号投出一张选票，按照先来先服务的原则。
3.3 要求大多数选票的规则确保了最多只会有一个候选人赢得此次选举。 一旦候选人赢得选举，他就立即成为领导人。然后他会向其他的服务器发送心跳消息来建立自己的权威并且阻止新的领导人的产生
4.1 在等待投票的时候，候选人可能会从其他的服务器接收到声明它是领导人的附加日志项 RPC。
-
如果这个领导人的任期号（包含在此次的 RPC中）不小于候选人当前的任期号，那么候选人会承认领导人合法并回到跟随者状态。
-
如果此次 RPC 中的任期号比自己小，那么候选人就会拒绝这次的 RPC 并且继续保持候选人状态。
4.2 候选人第三种可能的结果是既没有赢得选举也没有输：
-
如果有多个跟随者同时成为候选人，那么选票可能会被瓜分以至于没有候选人可以赢得大多数人的支持。
-
当这种情况发生的时候，每一个候选人都会超时，然后通过增加当前任期号来开始一轮新的选举。
-
然而，没有其他机制的话，选票可能会被无限的重复瓜分。 为了解决这个问题，Raft 增加了一个“时间随机选择机制”，选举超时时间是从一个固定的区间（例如 150-300 毫秒）随机选择，这样就使得每个节点发送 RPC 请求的时间错开。
4.3 选举限制。请求投票 RPC 实现了这样的限制：RPC 中包含了候选人的日志信息，然后投票人会拒绝掉那些日志没有自己新的投票请求。
查看选举限制（论文译文）
在任何基于领导人的一致性算法中，领导人都必须存储所有已经提交的日志条目。 在某些一致性算法中，例如 Viewstamped Replication，某个节点即使是一开始并没有包含所有已经提交的日志条目，它也能被选为领导者。 这些算法都包含一些额外的机制来识别丢失的日志条目并把他们传送给新的领导人，要么是在选举阶段要么在之后很快进行。 不幸的是，这种方法会导致相当大的额外的机制和复杂性。 Raft 使用了一种更加简单的方法，它可以保证所有之前的任期号中已经提交的日志条目在选举的时候都会出现在新的领导人中，不需要传送这些日志条目给领导人。 这意味着日志条目的传送是单向的，只从领导人传给跟随者，并且领导人从不会覆盖自身本地日志中已经存在的条目。
Raft 使用投票的方式来阻止一个候选人赢得选举除非这个候选人包含了所有已经提交的日志条目。 候选人为了赢得选举必须联系集群中的大部分节点，这意味着每一个已经提交的日志条目在这些服务器节点中肯定存在于至少一个节点上。 如果候选人的日志至少和大多数的服务器节点一样新（这个新的定义会在下面讨论），那么他一定持有了所有已经提交的日志条目。 请求投票 RPC 实现了这样的限制：RPC 中包含了候选人的日志信息，然后投票人会拒绝掉那些日志没有自己新的投票请求。
5.1 心跳机制和超时机制触发领导者选举
5.2 选举的两个过程：跟随者增加任期号，转换状态至候选者状态；维持当前状态，并发送请求投票的 RPCs，直至出现三种情况（事件），可能（没有获胜者）触发“时间随机选择机制”。