Part 05：Raft论文翻译-《CONSENSUS: BRIDGING THEORY AND PRACTICE》（基础Raft-Leader选举）
3.4 Leader Election（Leader选举）
Raft使用心跳机制来触发Leader选举。当服务器启动时，它们一开始是Follower。只要服务器从Leader或Candidate接收有效的rpc，它将处于Follower状态。Leader定期向所有Follower发送心跳(没有Log Entry的RPC请求)，以维持Leader状态。如果Follower在被称为选举超时的时间内没有收到来自Leader的通信，那么它就假设没有有效的Leader，那么这个Follower就会编程Candidate并开始选举来选择新的Leader。
当开始选举时，Candidate将增加其当前的任期，并过渡到Candidate状态。然后，它为自己投票，并与集群中的每个其他服务器并行地发出RquestVote RPC请求。一个Candidate继续这个状态，直到以下三件事发生：(a)它赢得选举，(b)另一个服务器确立自己作为Leader，或者(c)选举超时，没有获胜者。这些结果将在下文的段落中分别进行讨论。
如果Candidate在同一term内获得来自整个集群中大多数服务器的投票，他将赢得选举。每个服务器将在给定任期内以先到先得的基础上最多投票一名候选人（注：第3.6节增加了对投票的额外限制）。多数派的选举规则确保最多有一个Candidate可以赢得特定term的选举（图3.2中的选举安全属性）。一旦一个Candidate赢得了一次选举，它就会成为Leader。然后，它向所有其他服务器发送心跳消息（通过AppendEntries RPC），以通知其胜选消息并防止新的选举。
在等待投票时，Candidate可能会从另一个服务器接收到一个 AppendEntries RPC消息声称自己是Leader。如果Leader的term(包括在其RPC中)至少与Candidate的当前任期相同，那么Candidate就会承认Leader是合法的，并返回到Follower状态。如果RPC中的term小于Candidate的当前term，则Candidate拒绝RPC并继续处于候选状态。
第三个可能的结果是，Candidate既不获胜也不失败：如果许多Follower同时成为Candidate，选票可以被分割，因此没有Candidate获得多数选票。当这种情况发生时，每位Candidate将超时，通过增加term和启动另一轮请求投票，开始新的选举。然而，如果没有额外的措施，分裂的投票可能会无限期地重复。
Raft使用随机选举超时，以确保分裂选票罕见，并迅速解决。为了防止投票分裂，首先是从一个固定的时间间隔（例如，150-300毫秒）中随机选择选举超时。这将使服务器分散，以便在大多数情况下，只有一个服务器将超时；它赢得选举，并在任何其他服务器超时之前发送心跳。同样的机制也用于处理分裂投票。每位Candidate在选举开始时重新开始其随机选举的超时，并等待超时后开始下一次选举；这降低了新选举中再次分裂投票的可能性。第9章表明，这种方法可以迅速选出一Leader。
选举就是可理解性指导我们选择的一个例子。最初我们计划使用一个排名系统：每个Candidate被分配一个唯一的排名，用于在相互竞争的Candidate之间进行选择。如果一个Candidate发现了另一个排名较高的Candidate，它将回到追Follower，这样排名较高的Candidate就可以更容易地赢得下次选举。我们发现，这种方法围绕可用性产生了微妙的问题（如果排名较高的服务器失败，排名较低的服务器可能需要超时并再次成为Candidate，但如果这样做得过早，它可以重置选择Leader的进度）。我们对算法进行了几次调整，但每次调整后都出现了新的特殊情况。最终，我们得出结论，随机重试方法更明显和更容易理解。
这里用下面的流程图说明一下Leader Election的流程，一遍更加直观的说明Leader Election流程。首先要说明的是，发起选举的服务器起始状态是Follower，当其在预设的时间间隔内未收到来自Leader的心跳（也就是AppendEntries RPC请求），那么其就编程Candidate并发起新的选举。这里有一个问题，如果是这个Follower服务器与Leader的网络通信断开/延迟时间过长，那么这个服务器也会执行重新选举的操作。可以考虑一下，如果仅仅是Leader和这个Follower之间的网络通信出现问题，其它Leader和其它Follower之间以及所有Follower之间的网络通信正常，这样也会导致重新选举，而这样又会导致新的Leader和当前Leader（当前Leader后面将变为Follower）之间的网络不通，这里存在一个问题：老的Leader会不会发起新的Leader选举请求？就算老的Leader不会发起新的选举，那这个操作其实就是互换了一下Leader和Follower，但是要存在多余的Log复制操作，其实没有必要。（本人暂时还没有想到好的解决方法，看看后面的文章有没有回答这个问题）。
还需要说的是，这里Candidate进行选举时可能存在分裂的问题，Raft使用了随机超时的方法降低选举分裂概率，这个方法不一定是最好的，但是是比较容易理解的，这也服务Raft算法的设计目标（可理解性至上）。
