運行並行Paxos實例時的競爭條件

Question

我對使用Paxos算法感到困惑。 似乎Paxos可以用於這種情況：多個服務器（一個集羣，我假設每個服務器都有3個角色，提議者，接受者，精簡者）需要保持相同的命令序列以實現一致性和備份。我假設有一些客戶端向這臺服務器發送命令（客戶端可以並行發送）。每次通過一個Paxos實例將該命令分派給多個服務器時。

1. 不同的客戶端可以發送不同的命令給不同的提議者，對嗎？

如果是這樣，來自某個客戶端的一個命令將引發一個Paxos實例。所以，

1. 多個Paxos實例可能同時運行？

如果是這樣，客戶端A向提議者A發送「A + = 1」命令，並且客戶端B幾乎同時向提議者B發送「B + = 2」命令，我想看到每個服務器都收到2條命令，「A + = 1」和「B + = 2」。

然而，

鑑於5級的服務器，說S1-S5，S1發送命令 「A + = 1」 和S5發送命令 「B + = 1」，S2承諾S1然而S3，S4承諾S5，所以最終S3，S4，S5得到了「B + = 1」，但是S1，S2沒有得到，因爲承諾的數量不是多數。看起來像Paxos根本沒有幫助。我們在所有5臺服務器上都沒有得到預期的「A + = 1」和「B + = 2」？

所以我猜在Paxos的實際應用中，沒有平行的Paxos實例被允許？如果是這樣，如何避免平行Paxos實例，似乎我們仍然需要一個集中服務器來標記是否有Paxos正在運行，如果我們允許多個客戶端和多個提議者。

此外，我對提案人編號有疑問。我搜索互聯網和一些索賠以下
是一個解決方案： 5個服務器，給定相應的索引k（0-4），每個服務器使用數字5 * i + k爲這個服務器的第i個建議。

對於我來說，這似乎不符合要求的重要，因爲服務器-1的第一個提案數量始終爲1和服務器4的第一個提案數量始終是4，但服務器4可能早於提高提案server-1，但是它的提案號碼更大。

Answer 1

所以我猜在Paxos的實際應用中，不允許並行Paxos 實例嗎？如果是這樣，如何避免平行Paxos實例，如果我們允許多個客戶端和多個 提案者，似乎我們仍然需要一個集中式服務器來標記是否有 Paxos正在運行。

您不需要集中式服務，只需要節點將客戶端重定向到當前領導者。如果他們不知道誰是領導者，他們應該拋出一個錯誤，並且客戶端應該從DNS/config中選擇另一個節點，直到他們找到或被告知當前領導者。客戶只需要一個合理的最新的集羣中的節點列表，以便他們可以聯繫大多數當前節點，然後當穩定時他們會找到領導。

如果在網絡分區期間節點分離，您可能會感到幸運，並且它的乾淨和穩定的分區只會導致一個多數，它將得到一個新的穩定的領導者。如果你得到一個不穩定的分區或者一些被丟棄的定向分組，使得兩個或者多個節點開始成爲「決鬥領導者」，那麼你可以使用隨機超時和自適應回退來最小化試圖同時選舉產生的兩個節點，導致輪次失敗和浪費的消息。客戶將得到浪費的重定向，錯誤或超時，並將在決鬥期間掃描領導者，直至解決問題爲穩定的領導者。

有效的paxos會將CP從CAP中取出，因此由於決鬥領導或沒有多數人能夠溝通，它可能會失去A（可用性）。也許如果在實踐中真的存在高風險，那麼人們會寫關於讓節點將任何反覆嘗試領導的節點列入黑名單，但由於持續不穩定的網絡分區問題而無法提交的節點。實際上，人們可以想象，在嘗試將複雜的「無人看管」功能添加到協議中之前，監控系統的人員會收到警報並殺死這樣的節點並修復網絡。

關於提議的數量，一個簡單的方案是一個64位長，32位計數器打包到最高位和節點的32位IP地址打包到最低位。這使得所有的數字都是唯一的和交錯的，只是假設你不在同一臺機器上運行多個節點。

如果你看看維基百科上的Multi-Paxos，它是關於優化穩定領導者的流程。故障轉移應該非常少見，所以一旦你找到領導者，它可以只接受消息並跳過提案。如果您正在將領導者身份包裝到事件編號中，那麼當您在奔波時，節點可以看到後續接受來自同一個領導者，並且對於該領導者是順序的。與穩定的領導者一起舞動是一個很好的優化，並且創建一個新的領導者提案是一個昂貴的事情，需要提案信息，而且應該避免決鬥領導者的風險，除非它是集羣啓動或故障轉移。

Answer 2

然而它的提案數量更大。

這正是劃分提案空間的要點。規則是，只有最近的提案，即所見最多的提案才能被接受。因此，如果發出三個提案，則只有一個提案數量最多的提案才能獲得公認的多數。

如果你不這樣做，很可能會有多方繼續用瘋狂的簡單遞增數字（nextNumber = ++highestNumberSeen）吐出提案，並且從未達成共識。