基於paxos的複製密鑰值存儲區的領導者選舉

Question

我將使用多個Paxos實現關鍵值存儲區。我會有幾個節點，其中之一是主節點。該主節點接收更新請求並將值複製到從節點。

我的問題是如何選擇主節點（或領導者）？我仍然可以使用Paxos算法嗎？如果是這樣，你認爲有必要抽象的Paxos實現在單個單元，不僅可以通過複製單元，而且也對地區領導人選舉單位？

如果我用最少的ID的節點是使用領導人？我怎樣才能實現主租約？

感謝您的任何答案。

Answer 1

在開始討論實際問題之前，我建議對於類似paxos的系統，您不要將其視爲主從關係，而應該將其視爲等同關係。基本的Paxos甚至沒有領導者的概念。 Multi-paxos將領導者作爲性能優化工具，選擇領導者作爲協議的一部分。

Multi-Paxos歸結爲下面的Paxos：有一個準備階段和一個接受階段。 Multi-Paxos的洞察力是，一旦一個節點贏得了接受回合，它就同時贏得了領導者選舉，然後在該領導者沒有必要準備階段，直到它發現另一個節點已經接管領導。

---

現在一些實際意見。我在多個paxos，multi-paxos和其他共識系統上工作多年。

我第一次建議不是實現Paxos或Multi-paxos。特別是如果你有這些類型的問題，優化Paxos系統的性能，同時保持它的正確性非常難—。我會代替考慮實施Raft協議。

既然這兩種協議都是正確的，Raft協議可以比Multi-Paxos有更好的吞吐量。 Raft作者（和其他人）認爲，Raft更易於理解和實施。

你也可以考慮使用其中一個開源的Raft系統。我沒有任何經驗告訴你維護是多麼容易。不過，我聽說維護Zookeeper實例時很痛苦。 （我也聽說了有關Zookeeper的正確性證明的抱怨。）

接下來，已經證明每個共識協議可以永久循環。在您的系統中構建一個超時機制，並在適當的時候隨機退避。這就是實際的工程師如何解決理論上的不可能。

最後，檢查您的吞吐量需求。如果您的吞吐量足夠高，則需要弄清楚如何劃分多個共識集羣。這是一個完整的蠟球。

Answer 2

您可以使用並行multi-paxos實例解決此問題，以管理羣集的配置。考慮到威盛多的Paxos更新複製JSON對象包含以下信息：

• 序列號
• 當前領導者ID
• 目前處於領先地位的租約到期的時間戳
對IDS的
• 名單

您可以使用庫存paxos實現並將所有必需的邏輯放入網絡層：

• 刪除從領導以外的任何節點收到的所有Prepare和Accept消息，直到租約到期。
• 在租約到期前不久，主動提起序列號和領隊的租約時間。