在 PAXOS 或 RAFT 中重新上線的副本如何趕上？

Question

在諸如 PAXOS 和 RAFT 之類的共識算法中，會提出一個值，如果法定人數同意，則將其持久地寫入數據存儲。 在達到法定人數時無法參加的參與者會怎樣？ 他們最終如何趕上？ 無論我在哪里看，這似乎都留給讀者作為練習。

Answer 1

看一下 Raft 協議。 它只是內置在算法中。 如果領導者跟蹤要發送給每個追隨者的最高索引（ matchIndex ）和下一個nextIndex ，並且領導者總是從追隨者的nextIndex開始向每個追隨者發送條目，則不需要處理追趕丟失的追隨者的特殊情況提交條目時。 從本質上講，當重新啟動時，領導者將始終從其日志中的最后一個條目開始向該跟隨者發送條目。 因此節點被趕上。

Answer 2

對於原始的 Paxos 論文，它確實留給讀者作為練習。 在實踐中，使用 Paxos，您可以發送額外的消息，例如否定確認，以在集群周圍傳播更多信息，作為性能優化。 這可用於讓節點知道它由於丟失消息而落后。 一旦一個節點知道它落后了，它就需要趕上這可以通過其他消息類型來完成。 這被描述為 Trex multi- paxos引擎中的 Retransmission，我編寫該引擎是為了揭開 Paxos的神秘面紗。

Google Chubby paxos 論文Paxos Made Live批評 Paxos 將很多事情留給了執行人員。 Lamport 接受過數學培訓，並試圖在數學上證明當他找到解決方案時，您無法就有損網絡達成共識。 原始論文在很大程度上提供了一個證明它是可能的，而不是解釋如何用它來構建實際系統。 現代論文通常描述由一些實驗結果支持的一些新技術的應用，同時它們也提供正式的證明，恕我直言，大多數人跳過它並相信它。 引入 Paxos 的不可接近的方式意味着許多引用原始論文但沒有看到他們描述領導選舉和多 Paxos 的人。 不幸的是，Paxos 仍然是以理論的方式教授的，而不是現代的風格，這導致人們認為它很難，錯過了它的本質。

我認為Paxos 很簡單，但對分布式系統中的故障進行推理並進行測試以發現任何錯誤卻很困難。 原始論文中留給讀者的所有內容都不會影響正確性，但會影響延遲、吞吐量和代碼的復雜性。 一旦您了解了 Paxos 正確的原因，因為它在機械上很簡單，就可以在為您的用例和工作負載優化代碼時以不違反一致性的方式直接編寫所需的其余部分。

例如， Corfu和CURP提供了非常高的性能，一個僅將 Paxos 用於元數據，另一個僅在對相同鍵進行並發寫入時才需要使用 Paxos。 這些解決方案不能直接與 Raft 或 Multi-Paxos 一起完成，因為它們解決了特定的高性能場景（例如，kv 存儲）。 然而，它們表明值得理解的是，對於實際應用程序，如果您的特定工作負載允許您在整體解決方案的某些部分仍然使用 Paxos，您可以進行大量優化。

Answer 3

Paxos made Simple 中提到了這一點：

由於消息丟失，可以在沒有學習者發現的情況下選擇一個值。 學習者可以詢問接受者他們接受了哪些建議，但接受者的失敗可能會導致無法知道大多數人是否接受了特定的建議。 在這種情況下，學習者只會在選擇新提案時才知道選擇了什么值。 如果學習者需要知道一個值是否被選擇，它可以讓提議者使用上述算法發出提議。

還有在 Raft 紙上：

領導者為每個追隨者維護一個 nextIndex，這是領導者將發送給該​​追隨者的下一個日志條目的索引。

---

如果一個 follower 的 log 與 leader 的不一致，那么 AppendEntries 一致性檢查將在下一個 AppendEntries RPC 中失敗。 拒絕后，領導者減少 nextIndex 並重試 AppendEntries RPC。 最終 nextIndex 將達到領導者和追隨者日志匹配的點。 發生這種情況時，AppendEntries 將成功，這將刪除跟隨者日志中的任何沖突條目並附加領導者日志中的條目（如果有）。

---

如果跟隨者或候選者崩潰，那么未來發送給它的 RequestVote 和 AppendEntries RPC 將失敗。 Raft 通過無限期重試來處理這些失敗； 如果崩潰的服務器重新啟動，那么 RPC 將成功完成。