當領導者提交日志條目並在通知跟隨者該承諾之前崩潰時，raft如何保持安全？

Question

在我的理解中，leader 向 follower 發送 AppendEntries RPC，如果大多數 follower 返回成功，leader 將提交該條目。 它將通過將其應用到自己的 state 機器上來提交此條目，並且它還將返回給客戶端以讓客戶端知道命令成功。

但是，此時，追隨者還不知道這一承諾。 它將在下一個 AppendEntries（或心跳）RPC 調用中通知關注者。

在最簡單的情況下，如果leader在commitment之后和下一個AppendEntries之前崩潰，raft會使用“只有最新的follower才能獲勝”的策略來確保下一個leader必須包含這個日志條目（盡管沒有提交），並且新的領導者將提交此條目並將 AppendEntries 發送給其他追隨者。 這樣，日志條目就被安全地保存了。

但是，請考慮以下復雜情況（摘自 PHD 論文“共識：橋接理論與實踐”第 23 頁）。

此時，第 2 期的日志條目已在大多數服務器上復制，但尚未提交。 如果 S1 像 (d1) 中那樣崩潰，S5 可以被選舉為領導者（來自 S2、S3 和 S4 的投票）並用它自己的第 3 期條目覆蓋條目。

如果此時，它已在服務器 S1 中提交，但尚未在其他服務器中提交，該怎么辦？ 如果 S1 然后像 (d1) 那樣崩潰，這個日志條目會被 S5 覆蓋嗎？

在我的理解中，一個提交的條目（應用於 state 機器並可能通知客戶端結果）永遠不會被覆蓋？

我對 raft 協議有什么誤解嗎？

謝謝。

Answer 1

Raft 中有更多的條件來提交條目。

在本文的第 4 頁（筏的 1 頁摘要）它說

領導：

...

如果存在 N 使得 N > commitIndex，則 matchIndex[i] ≥ N 的大多數，並且 log[N].term == currentTerm 設置 commitIndex = N（§5.3，§5.4）。

換句話說，不僅條目必須被復制到多數，它的任期也必須來自當前任期。 這就是為什么在一個實際的系統中，一個新的領導者會提出一個 no-op 以便它可以推進這個 commitIndex。

所以現在我們知道領導者在那之前不會提交，但是如果它提交但不發送提交怎么辦。

稍后在同一篇論文的第 5.4.1 節中它說（強調我的）：

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.

簡而言之，根據定義，新領導者必須具有舊領導者認為已提交的條目。