当领导者提交日志条目并在通知追随者此承诺之前崩溃时，raft 如何保持安全？

Question

根据我的理解，领导者向追随者发送 AppendEntries RPC，如果大多数追随者返回成功，领导者将提交此条目。它会通过将其应用到自己的状态机来提交此条目，并且还会返回给客户端，让客户端知道该命令已成功。

然而，目前，追随者还不知道这一承诺。它将在下一个 AppendEntries（或心跳）RPC 调用中通知关注者。

在最简单的情况下，如果leader在提交之后、下一个AppendEntries之前崩溃，raft将使用“只有最新的follower才能获胜”策略来确保下一个leader必须包含这个日志条目（尽管没有提交），新的领导者将提交该条目并将 AppendEntries 发送给其他追随者。这样，日志条目就可以安全保存。

然而，请考虑以下复杂的场景（摘自博士论文“共识：理论与实践的桥梁”第 23 页）。

此时，第 2 项的日志条目已复制到大多数服务器上，但尚未提交。如果 S1 如 (d1) 那样崩溃，S5 可以当选为领导者（通过 S2、S3 和 S4 的投票）并用第 3 期中自己的条目覆盖该条目。

如果此时在服务器 S1 中已提交，但在其他服务器中尚未提交怎么办？如果 S1 然后像 (d1) 那样崩溃，该日志条目将被 S5 覆盖吗？

根据我的理解，提交的条目（应用于状态机并可能通知客户端结果）永远不会被覆盖？

我是否误解了筏协议的任何内容？

谢谢。

Answer 1

Raft 中有更多提交条目的条件。

\n

在本文的第 4 页（筏的 1 页摘要）上写着

\n

\n

领导：

\n

...

\n

如果存在 N > commitIndex，则大多数 matchIndex[i] \xe2\x89\xa5 N，且 log[N].term == currentTerm set commitIndex = N (\xc2\xa75.3, \xc2 \xa75.4)。

\n

\n

换句话说，不仅该条目必须复制到大多数，而且其术语也必须来自当前术语。这就是为什么在实际系统中，新的领导者会提出一个无操作，以便它可以推进这个提交索引。

\n

现在我们知道领导者在那之前不会提交，但是如果它提交但没有发送提交怎么办？

\n

后来在同一篇论文的第 5.4.1 节中提到（强调我的）：

\n

\n

Raft...保证从选举那一刻起，每个新领导者都会出现之前任期中所有已提交的条目...Raft 使用投票过程来防止候选人赢得选举，除非其日志包含所有已提交的条目。候选者必须联系集群的大多数才能当选，这意味着每个提交的条目必须至少存在于其中一台服务器中。

\n

\n

简而言之，根据定义，新领导者必须拥有旧领导者认为已提交的条目。

\n