paxos演算法第二階段的必要性是什麼？

paxos演算法第一階段是prepare請求，第二階段是accept請求。

因為在prepare階段，某投票拿到過半acceptor同意，已經能保證投出來的值是唯一的。為什麼還要發出accept請求呢，並且當某個accepter已經響應一個更大的投票時，該accept請求會被拒絕，這樣設計的原因是什麼？

已經看了The Part Time Parliament, Paxos Made Simple，還是找不到答案，求大神解惑~~

為什麼還需要Accept階段，因為Prepare無法保證投票的唯一性，一個Proposer 以proposal-id=1在Prepare階段拿了過半的贊同，另一個Proposer以一個更大的proposer-id，例如為2，顯然也能拿到過半的贊同。

這裡舉個例子來簡單說明如果Acceptor不拒絕比它響應過的提案更小的提案會如何：

A,B,C三個Proposer，同時它們也是Acceptor，A首先通過了Prepare階段，準備以值a提出它的Proposal，而B在A通過Prepare階段和發起Accept階段之間，以一個更大的proposal-id，完成了Prepare和Accept階段，假設B提出的是值是b，不等於A提出的值a，那麼顯然如果Acceptor無法拒絕A提出的Proposal，那麼協議一致性就會得到破壞。

但是實際上你是不能割裂Paxos的步驟來理解，它的每一步只有合在一起才能保證協議的正確性。樓主說的兩篇論文里是有完整和非常精彩和詳細的論述的，講真這個是需要自己花時間的。

題主把問題假設在了 「在basic paxos 中，一個proposal 已經被chosen了」，認為在這樣的假設的情況下，通過一個prepare階段就可以獲知值，而無需 accpet階段。簡單來說，就是題主的問題是「明明一個階段可以解決的一致性問題，為什麼要擴展到兩個階段？」。但是這個問題是在題主的強假設 才有可能成立的。題主在問這個問題的時候，顯然是默認了 一個proposal已經被chosen了，後續的proposer只需 prepare階段就可以得知 被chosen 的proposal。但是如果假設 「現在沒有任何propsal 被chosen，並且多個proposer同時提議多個不同的proposal」，那顯然一個階段是不可能保證一致性的，是必須用兩階段才可以保證一致性的。而這也正是basic paxos 的精華所在 「如何確保在沒有proposal 被chosen，多個 proposer提出不同的value，最終依然能夠保證 chosen的proposal的一致」。

另外其實題主提到的用一個階段來得到一個一致的結果也是可行的，不過不是在prepare階段，而是在accpet階段而已，但是這還是必須prepare一次才可以的，這也是multi-paxos 的巧妙所在。

懂得不多，希望能夠解答題主的問題，有錯歡迎指正。

兩階段是最終的體現形式。而為什麼一定需要這兩個階段，因為它是保證consensus的充分條件。不是充要條件噢，你要能找到充要條件那就厲害了親！兩階段其實是： 多acceptor 情況下，p1a、p2c、promise 的綜合體。在多acceptor 情況下，具體的推理流程大概是（=》表示前者是後者的充分條件）：

p1+acceptor可以accept多個提案+p2 =》consensus；

（p1a+p2c+promise）（也就是所謂的兩階段）=》consensus 。

首先，考察題主說的方法：某個proposer拿到多數派的acceptor的投票就達成最終的結論。

這種方法的一致性是有問題的：

1. 假設acceptor只能accept一次：假設N個acceptor分別accept了N個決議值，則接下來系統無法工作了，所以acceptor要能夠多次acceptor。

2. 假設acceptor可以接受任何proposal id的提議：那麼proposer p1和proposer p2都能夠拿到多數派的投票，例如p1拿到acceptor a/b，p2拿到acceptor b/c（b先後接受了p1和p2的兩個不同的決議）

其次，從Paxos證明過程看，Part Time那篇論文中，描述了三個約束B1、B2、B3。這其中B1和B2比較容易理解，B3是證明的關鍵。B3表達的意思是一個proposer想要發起決議時，首先要先learn系統的狀態而不能自己想提議什麼值就提議什麼值，是以需要兩個階段。

最後，直覺上，拒絕更小proposal id的請求是希望保持系統一直在處理fresh的請求，最好是每個acceptor都在處理當前最大proposal id的那一輪請求。本質上，因為非同步網路（消息可能丟失亂序），每個acceptor都要假設當前proposal id這一輪有可能未能達成多數派，所以要處理更新的一輪請求。Paxos的liveness活鎖也是多個proposer互相刷freshness導致的。

如果只有p階段，則會有兩種情況：

1. p階段使用搶佔式，也即一個acceptor(簡稱aor)可能會響應多個p請求，此時會造成多個proposer(簡稱por)獲得多數響應，從而無法達成一致。
2. p階段不使用搶佔式，先到先得，此時存在兩個以上的por同時發p請求的情況下，可能沒有por能獲得多數響應。

因此，二階段提交中，p階段實現資源搶佔和互通有無（獲得已經響應a請求的v值），a階段才能在p階段的基礎上，即防止多個por獲得多數響應，也防止沒有por獲得多數響應。