為什么 Paxos 設計分為兩個階段

Question

為什么 Paxos 需要兩個階段（ prepare/promise + accept/accepted ）而不是一個？ 也就是說，僅使用prepare/promise部分，如果提議者已收到大多數接受者的回復，則該值是選擇。

有什么問題，它是否破壞了安全性或活性？

Answer 1

不遵守完整的協議會破壞安全。

multi-paxos 的典型實現具有穩定狀態模式，其中穩定的領導者流Accept包含新值的消息。 只有在出現問題（leader 崩潰、停頓或被網絡問題分區）時，新的 leader 才需要發布准備消息以確保安全。 關於這一點的完整描述在TRex一個開源 Paxos 庫如何實現 Paxos 的文章中。

考慮以下TRex可以正確處理的崩潰場景：

1. 節點A , B , C以A前導
2. 客戶端應用程序將V1發送給領導者A
3. 節點A處於穩定狀態，因此將accept(n, V1)發送到節點B和C 。 網絡開始出現故障，因此只有B看到該消息並回復了accepted(n)
4. 節點A看到響應並擁有多數{A,B}因此它知道由於協議的安全性證明，該值是固定的。
5. 節點A嘗試在其服務器死機時將結果廣播給所有人。 只有發出V1的客戶端應用程序才能收到消息。 想象一下， V1是一個客戶訂單，並且在得知訂單是固定的時，客戶應用程序欠客戶信用卡的債務。
6. 節點C在死亡的領導者上超時並嘗試領導。 它從未看到值V1 。 它不能在不回滾訂單V1情況下任意選擇任何新值，但客戶已經被收費。
7. 所以節點C首先發出prepare(n+1) ，節點B以promise(n+1, V1)響應。
8. 然后節點C發出accept(n+1, V1)並且只要剩余的消息通過節點B和C就會知道選擇了值V1 。

直觀地說，我們可以說節點C通過選擇A的值來選擇與死節點A協作。 如此直觀地我們可以看出為什么必須有兩輪。 需要第一輪來發現是否有任何待完成的工作要完成。 第二輪用於修復正確的值，以在系統內的所有進程中提供一致性。

Answer 2

這並不完全准確，但您可以將這兩個階段視為 1) 復制數據，然后 2) 提交數據。 如果數據只是復制到其他服務器，這些服務器將不知道是否有足夠多的其他服務器擁有數據以使其被認為可以安全地提供服務。 因此有第二個階段讓服務器知道他們可以提交數據。

Paxos 比這稍微復雜一點，它允許它在任一階段出現故障時繼續運行。 Paxos 證明的一部分是它是完全執行此操作的最小協議。 也就是說，其他協議做了更多的工作，要么是因為它們添加了更多的功能，要么是因為它們的設計很差。