筏如何保证可以始终选出领导者？
Raft 论文 说：
Raft 使用投票过程来阻止候选人赢得选举 选举，除非其日志包含所有已提交的条目。候选人 必须联系集群的大多数才能当选，这 意味着每个提交的条目必须至少出现在以下之一中 那些服务器。如果候选人的日志至少是最新的 其他登录占多数，那么它将保留所有已提交的 条目。 RequestVote RPC 实现了这个限制：RPC 包含有关候选人日志的信息，但选民否认 如果自己的日志比候选人的日志更新，则投票
然而，它如何保证总是甚至有一个可以当选的领导者（即与最新的领导者一样）日期作为集群的大多数）？
例如，假设我们有一个由三台服务器 A、B、C 组成的集群，其中 A 为领导者。第一个日志条目存储在 A 和 B 中，第二个日志条目存储在 A 和 C 中。然后 A 崩溃，B 和 C 尝试选举领导者。但此时不存在大多数（即三分之二）服务器同时具有第一和第二条目。所以看起来领导者选举永远不会发生（除非 A 重新启动，但 Raft 应该能够适应三分之一服务器的故障..）
The Raft paper says:
Raft uses the voting process to prevent a candidate from winning an
election unless its log contains all committed entries. A candidate
must contact a majority of the cluster in order to be elected, which
means that every committed entry must be present in at least one of
those servers. If the candidate’s log is at least as up-to-date as any
other log in that majority, then it will hold all the committed
entries. The RequestVote RPC implements this restriction: the RPC
includes information about the candidate’s log, and the voter denies
its vote if its own log is more up-to-date than that of the candidate
How does it guarantee, however, that there will always even be an electable leader (i.e. one that's as up-to-date as a majority of cluster)?
For example, let's say we have a cluster of three servers A, B, C with A as the leader. First log entry is stored in A and B, second log entry is stored in A and C. Then A crashes, and B and C try to elect a leader. But at this point there is no majority (i.e. 2 out of 3) servers that have both first and second entries. So it seems like leader election can't ever happen (unless A restarts, but Raft's supposed to be resilient to a failure of 1 out of 3 servers..)
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
论文定义了一个与该场景相关的“日志匹配属性”：
由于 A 和 C 都包含相同的第二个条目，因此 C 也必须包含第一个条目。这是可以保证的，因为：
在 C 拥有 B 拥有的条目之前，它将拒绝进一步的追加。因此，在您的场景中的某个时刻，C 必须收到该条目才能最终接受来自 A 的新条目。
因此，C 是 B 和 C 之间最新的条目。（它将拒绝 B 的领导投票。）
The paper defines a "Log Matching Property" that is relevant to this scenario:
Since A and C both contain the same second entry, C must also contain the first entry. This is ensured because:
Until C has the entry that B has, it will reject further appends. So at some point in your scenario, C must have received that entry to finally accept the newer entry from A.
Therefore, C is the most up to date between B and C. (It would reject a leadership vote from B.)