在RAFT中，是否可以在日志條目上達成多數共識，但條目未提交？

Question

在官方筏網頁上考慮這種模擬

盡管S2 (leader) ， S3和S4同意日志，為什么第term 2 index 1沒有提交？ 我運行這幾分鍾以確保所有通信都已發生。

奇怪的是，如果我再添加一個日志條目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中的問題，Raft從不通過計算副本來提交先前術語的日志條目。 通過計算副本，只提供領導者當前術語的日志條目; 一旦以這種方式提交了當前術語的條目，則由於日志匹配屬性而間接提交所有先前條目。 在某些情況下，領導者可以安全地斷定提交了較舊的日志條目（例如，如果該條目存儲在每個服務器上），但是Raft采用更保守的方法來簡化

您的示例完美地設置為顯示為什么這是不安全的。 讓我們假設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處覆蓋其值2 。
7. S5接收並應用AppendEntries([4]) 。
8. S1在本地提交4
   • 我們打破了!! 兩個承諾的價值觀
9. S2，S3接收並應用AppendEntries([4]) 。
   • 我們已經倍加打破它，我們丟失了承諾的數據!!
   • 一個優秀的工程師會在這里設置一個斷言以捕獲這個覆蓋。

發生了什么？ 實質上，我們為同一個時段選出了兩個不同的領導者。 （當S1更新時，S2當選為領導者。）

那么為什么領導者在沒有等待后續請求的情況下提交自己的條款是否安全呢？ 因為不可能進入上述情況。 讓我們考慮兩個節點（S2，S1）分別認為它們在第2和第3項中同時是領導者的情況。 如果S2准備好將2提交到插槽1，那么大多數在那里具有相同的值。 這意味着沒有多數人投票支持在插槽1中有更高期限的任何其他任何東西。這意味着S1，在第3階段當選為領導者，在第1個插槽中必須有2個。

（順便說一句，我花了一分鍾才弄清楚你是如何進入這種情況的。）

另外，Raft被稱為“Paxos更易理解的版本”。 我不同意：它似乎有這么多（如果不是更多）角落案例。 但是，Raft的作者非常善於讓工程師輕松地正確實現某些實用的東西。 這與作者如何撰寫筏紙有關。