当领导者提交日志条目并在通知追随者此承诺之前崩溃时，筏如何保持安全？
How does raft preserve safty when a leader commits a log entry and crashes before informing followers this commitment?
在我的理解中，leader 向 followers 发送 AppendEntries RPC，如果大多数 followers return 成功，leader 将提交此条目。它将通过将其应用于自己的状态机来提交该条目，并且还将return发送给客户端，让客户端知道命令已成功。
不过，目前追随者还不知道这项承诺。它将在下一个 AppendEntries（或心跳）RPC 调用中通知追随者。
在最简单的情况下，如果leader在提交之后和下一个AppendEntries之前崩溃了，raft将使用“只有最新的follower才能获胜”策略来确保下一个leader必须包含这个日志条目（尽管未提交），新的领导者将提交此条目并将 AppendEntries 发送给其他跟随者。这样，日志条目就安全保存了。
但是，请考虑以下复杂情况（摘自 PHD 论文“共识：桥接理论与实践”第 23 页）。
At this point, the log entry from term 2 has been replicated on a
majority of the servers, but it is not committed. If S1 crashes as in
(d1), S5 could be elected leader (with votes from S2, S3, and S4) and
overwrite the entry with its own entry from term 3.
如果此时，它在服务器 S1 中提交，但尚未在其他服务器中提交怎么办？如果 S1 然后像 (d1) 中那样崩溃，此日志条目将被 S5 覆盖？
据我了解，提交的条目（应用于状态机并可能将结果告知客户端）永远不会被覆盖？
我是不是对 raft 协议有什么误解？
谢谢。
Raft中提交条目的条件更多。
在 this paper 的第 4 页（Raft 的第 1 页摘要）它说
Leaders:
...
If there exists an N such that N > commitIndex, a majority of matchIndex[i] ≥ N, and log[N].term == currentTerm set commitIndex = N (§5.3, §5.4).
换句话说，不仅条目必须复制到多数，它的任期必须来自当前任期。这就是为什么在实际的系统中，一个新的领导者会提出一个 no-op，以便它可以推进这个 commitIndex。
所以现在我们知道领导者在那之前不会提交，但是如果它提交但没有发送提交怎么办。
稍后在 section 5.4.1 of the same paper 它说（强调我的）：
Raft...guarantees that all the committed entries from previous terms are present on each new leader from the moment of its election....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.
简而言之，根据定义，新领导者必须具有旧领导者认为已提交的条目。
在我的理解中，leader 向 followers 发送 AppendEntries RPC，如果大多数 followers return 成功，leader 将提交此条目。它将通过将其应用于自己的状态机来提交该条目，并且还将return发送给客户端，让客户端知道命令已成功。
不过，目前追随者还不知道这项承诺。它将在下一个 AppendEntries（或心跳）RPC 调用中通知追随者。
在最简单的情况下，如果leader在提交之后和下一个AppendEntries之前崩溃了，raft将使用“只有最新的follower才能获胜”策略来确保下一个leader必须包含这个日志条目（尽管未提交），新的领导者将提交此条目并将 AppendEntries 发送给其他跟随者。这样，日志条目就安全保存了。
但是，请考虑以下复杂情况（摘自 PHD 论文“共识：桥接理论与实践”第 23 页）。
At this point, the log entry from term 2 has been replicated on a majority of the servers, but it is not committed. If S1 crashes as in (d1), S5 could be elected leader (with votes from S2, S3, and S4) and overwrite the entry with its own entry from term 3.
如果此时，它在服务器 S1 中提交，但尚未在其他服务器中提交怎么办？如果 S1 然后像 (d1) 中那样崩溃，此日志条目将被 S5 覆盖？
据我了解，提交的条目（应用于状态机并可能将结果告知客户端）永远不会被覆盖？
我是不是对 raft 协议有什么误解？
谢谢。
Raft中提交条目的条件更多。
在 this paper 的第 4 页（Raft 的第 1 页摘要）它说
Leaders:
...
If there exists an N such that N > commitIndex, a majority of matchIndex[i] ≥ N, and log[N].term == currentTerm set commitIndex = N (§5.3, §5.4).
换句话说，不仅条目必须复制到多数，它的任期必须来自当前任期。这就是为什么在实际的系统中，一个新的领导者会提出一个 no-op，以便它可以推进这个 commitIndex。
所以现在我们知道领导者在那之前不会提交，但是如果它提交但没有发送提交怎么办。
稍后在 section 5.4.1 of the same paper 它说（强调我的）：
Raft...guarantees that all the committed entries from previous terms are present on each new leader from the moment of its election....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.
简而言之，根据定义，新领导者必须具有旧领导者认为已提交的条目。