Raft 算法（一）Leader 选举

Leader election (Leader 选举)

Raft 使用心跳机制来触发 Leader 选举。当服务器启动的时候，他们的角色都是 follower。只要服务器没有从领导者(Leader) 或者候选者 (candidate) 这里收到有效的 RPC 请求，他就会维持 follower 状态。Leader 为了能够一直对 follower “发号施令”，他会发送周期性的心跳（不带Log Entries 的AppendEntries Rpc 请求）给所有 follower。如果一个follower在一段时间内没有收到心跳通信，这称之为 election timeout，这时候他会假设已经没有“在线”的 Leader 了并且会选举一个新的 Leader。

开始新的选举的时候，follower 会自增他自己的 term（任期） 并且转换为 candidate 状态。他自己会投自己一票，并且提交 RequestVote Rpc 请求给所有集群中的服务器。这个 candidate 会持续在这个状态中等待，直到这三件事中一件事发生：1、赢得选举；2、另一个服务器被确立为 Leader；3、一段时间内没有任何获选的服务器。这些情况会在下面进行单独讨论。

一个集群中的所有服务器在一个 term 中的只会有一个 candidate 会在半数票决中赢得选举。每个服务器在一个 term 中只能投票一次，并且是谁先请求谁先拿到票。半数票决确保了只有一个 candidate 能够在一个 term 中赢得这场选举。如果一个服务器赢得了选举，他讲会发送心跳包给所有其他的服务器去“建立他自己的政权“避免出现新的选举。

在等待被投票的过程中，一个 candidate 可能会收到从其他服务器成为 Leader 的 AppendEntries Rpc 请求。如果 Leader 的任期(include in its rpc)是最新的并和 candidate 的 current term 是一样大的，那么这个 candidate 会认为这个 leader 是合法的，并且这个 candidate 会从 candidate 状态转变为 follower 状态。

第二种可能的结果是，一个 candidate 既不没有赢得也没有输：在同一时间内很多 follower 都转变为 candidate，投票可能会被分开，因为没有 candidate 获取半数以上的票。当这个问题发生的时候，所有 candidate 将超时，并且开始了新一轮的选举——自增他们自己的 term 并且发送 RPC 请求给其他服务器。然而，没有额外的措施区分投票可能会导致无限的重复这个动作。

Raft 使用随机超时时间，随机的超时时间能够确保投票被拉开并且很快就能处理完毕。第一个避免分开投票的地方就是选举超时时间选择在固定的区间中（例如150-300ms）。这会分散服务器，在大多数情况下只有一个服务器会超时；在其他服务器超时之前他能够赢得选举并且发送心跳包。这个机制也被用于处理拆分投票。每个 candidate 会在开始一场选举的时候重新设置他自己的随机选举超时时间；这减少了出现新选举的可能性。

最初我们计划使用等级系统（rank system）：所有 candidate 被指定不同的 rank，使用 rank 来区分正在竞争中的 candidate。如果一个 candidate 发现其他 candidate 有比他自己高的 rank，那么他会转换为 follower 状态，高 rank 的 candidate 将会更容易在接下来的选举中赢得选举。但是我们发现这个途径产生了很微妙的问题，（一个低级的服务器需要高级的服务器宕机之后超时了才能再次成为 candidate，如果这样做得太早了，会重置选举进度）。我们花了一些时间调整算法，但是每次调整之后都会出现极端情况。最终我们还是觉得随机重试途径是最明显并且是最易懂的。