在RAFT中，有可能在日誌條目上達成多數共識，但條目未提交？

Question

考慮這個模擬在官方raft webpage

爲什麼term 2 index 1儘管不S2 (leader)，S3和S4致力於商定的日誌？我運行這個多分鐘來確保所有的溝通都已經發生。

奇怪的是，如果我再添加一個日誌條目term 6 index 2那麼將提交term 2 index 1。

有誰知道什麼是防止term 2 index 1規則被提交？

Answer 1

您的領導者在第6學期，但沒有一個日誌條目來自第6學期;這會在Raft中調用一條特殊規則。領導者不會自動提交前一個條目的條目，因爲在某些情況下，這樣做是不安全的。 5.3節和5.4節討論了這個問題（參見圖8）。

從5.4.2節：

爲了消除像在圖8中的問題，筏 從來不提交通過計算 副本日誌從以前的術語條目。只有領導者當前的 條款中的日誌條目通過對副本進行計數來提交;一旦來自當前項的條目 以這種方式承諾，則 ，則因爲日誌匹配屬性的 而間接承諾所有之前的條目。有些情況 其中的領導者可以有把握地斷定一個較舊的日誌條目 承諾（例如，如果該條目被存儲在每個 服務器上），但筏採取更保守的方法 爲簡單起見

你的例子完全是爲了說明爲什麼這是不安全的。我們假設S2 的確提交了，然後我們通過將兩件事物放入同一個插槽來打破它。

1. S2提交時隙1（局部地）。
2. S2發送AppendEntries(commitIndex=1, [])。
3. S3接收並應用AppendEntries(commitIndex=1)。
   • 2目前正致力於在兩臺主機。
   • 其他主機不收到消息。
4. S1當選領導人
   • S1是「更先進的日期」比任何其他日誌（§5.4.1）與易勝選舉。
5. S1發送AppendEntries([4])。
   • 的領導者做的第一件事是讓所有的其他日誌看起來像它自己。
6. S4接收並應用AppendEntries([4])。
   • 這在插槽1
7. S5接收並應用AppendEntries([4])覆蓋其值2。
8. S1承諾4本地
   • 我們已經打破它！兩個承諾值
9. S2，S3接收並應用AppendEntries([4])。
   • 我們加倍破壞它，我們丟失了承諾數據！
   • 一位優秀的工程師會在這裏提出一個斷言來抓住這個覆蓋。

發生了什麼事？實質上，我們選擇了兩個不同的領導者來選擇同一個位置。 （當S2更新時，S2被選爲領導者）

爲什麼領導者在不等待後續請求的情況下提交自己的詞條是安全的？因爲不可能進入上述情況。讓我們考慮兩個節點（S2，S1）分別認爲他們是領導者的情況。如果S2準備好將2提交到時隙1，那麼大多數在那裏具有相同的值。這意味着沒有多數人投票選擇第一個位置的任何一個更高的任期。這意味着S1將被選爲第3位的領導者，在第1位必須有2。

（順便說一下，花了我一分鐘你首先想到了這種情況。）

另一方面，Raft作爲「Paxos更易理解的版本」銷售。我不同意：似乎有這麼多（如果不是更多）角落案例。但是，Raft的作者非常善於讓工程師很容易地正確實施一些實用的東西。這與作者如何寫筏文件有關。