Raft 共识算法2-领导者选举

Raft 共识算法2-领导者选举

Raft算法中译版地址：https://object.redisant.com/doc/raft%E4%B8%AD%E8%AF%91%E7%89%88-2023%E5%B9%B44%E6%9C%8823%E6%97%A5.pdf

英原论文地址：https://raft.github.io/raft.pdf

Etcd Assistant 是一款 etcd 可视化管理软件，便捷高效地操作您的 etcd 集群；支持多种键的视图；管理租约、用户、角色和权限。

Raft 使用心跳机制来触发领导者选举。 当服务器启动时，它们以跟随者的身份开始。 只要服务器从领导者或候选者那里收到有效的 RPC，它就会保持跟随者状态。 领导者定期向所有跟随者发送心跳（不携带日志条目的 AppendEntries RPC），以维护自己的权威。 如果跟随者在称为选举超时（election timeout）的一段时间内没有收到任何通信，那么它会假定没有可行的领导者并开始选举以选择新的领导者。

为了开始选举，追随者增加其当前任期并转换到候选者状态。 然后它为自己投票并向集群中的每个其他服务器并行发出 RequestVote RPC。 候选者一直处于这种状态，直到发生以下三种情况之一：（a）它赢得了选举，（b）其他服务器确立了自己的领导地位，或者（c）一段时间内没有赢家。这些结果将在下面的段落中分别讨论。

如果一个候选者在同一任期内获得了整个集群中大多数服务器的投票，那么它就赢得了选举。每台服务器在给定的任期内最多为一名候选者投票，以先到先得为原则（注：第5.4节对投票增加了一个额外的限制）。少数服从多数的原则保证了最多只有一名候选者能够在某一任期内赢得选举（@fig3 中的选举安全（Election Safety））。一旦一个候选者在选举中获胜，它就成为领导者。然后，它向所有其他服务器发送心跳信息，以建立其权威并防止新的选举。

在等待投票时，候选者可能会收到来自另一台声称是领导者的服务器的 AppendEntries RPC。 如果领导者的任期（包含在其 RPC 中）至少与候选者的当前任期一样大，则候选者承认领导者是合法的并返回到追随者状态。 如果 RPC 中的任期小于候选者的当前任期，则候选者拒绝 RPC 并继续处于候选者状态。

第三种可能的结果是候选者既不赢也不输：如果许多追随者同时成为候选者，则可以平分选票，从而没有候选者获得多数票。 发生这种情况时，每个候选者都会超时并通过增加其任期并启动另一轮 RequestVote RPC 来开始新的选举。 然而，如果不采取额外措施，分裂投票可能会无限期地重复。

Raft 使用随机化的选举超时（election timeout）来确保分裂投票很少见并且可以快速解决。 为了首先防止分裂投票，选举超时是从固定间隔（例如，150-300 毫秒）中随机选择的。 这分散了服务器，因此在大多数情况下只有一个服务器会超时； 它赢得了选举，并在其他服务器超时之前发出心跳。 相同的机制用于处理分裂投票。 每个候选者在选举开始时重新启动其随机选举超时，并在开始下一次选举之前等待该超时结束； 这减少了在新选举中再次出现分裂投票的可能性。 9.3 节展示了这种方法可以快速选出领导者。

选举是可理解性如何指导我们在设计方案之间做出选择的一个例子。 最初我们计划使用排名系统：为每个候选者分配一个唯一的排名，用于在竞争候选者之间进行选择。 如果一个候选者发现了另一个排名更高的候选者，它会回到追随者状态，以便排名更高的候选者更容易赢得下一次选举。 我们发现这种方法在可用性方面产生了微妙的问题（如果排名较高的服务器出现故障，排名较低的服务器可能需要超时并再次成为候选者，但如果时间过早，它可能会重置选举领导者的进程 ). 我们对算法进行了多次调整，但每次调整后都会出现新的极端情况。 最终我们得出结论，随机重试方法更加明显和易于理解。