Make it Simple
Question：大名鼎鼎的Paxos協議是啥？Ansower：“分佈式一致性協議”。
這麼逼格的術語，就問你怕不怕？？能不能搞的中國話一點，簡單一點，而不是翻譯《Paxos Made Simple》呢？一直覺得Lesile Lamport的腦回路和常人不一樣好伐。文章前面部分一眼都懂，後面的，眼睛瞄瞎都不一定看得懂。本文是Paxos的一些閱讀總結。歡迎一起討論。
解決什麼問題
場景化的核心問題：成功的往分佈式系統裏面寫入一個數據。Outline幾個關鍵問題：
- 數據寫入模型是異步非阻塞，我們說的“同時”，都是指一次寫入未Finish的情況下就開始下一次的寫入；
- 各節點的數據一致，保證是最終一致；
- 失敗處理的兩個關鍵問題：失敗了是否會重試、重試的時候是否會增加ID，文中對失敗處理沒有太多的描述；
- 保證數據順序寫入，一旦一個寫入成功，後續就不會有ID更小的數據寫入成功。但並不是每一個“同時”的寫入操作都會寫成功，也不保證ID大的就一定會成功。
怎麼解決問題
我們循序漸展開思考解決之法。主要路徑是;
- All，寫入所有節點
- Quorum，寫入過半節點
- Rules， 競爭規則
- Same Value，等值情況怎麼應對
- Uncertainty，結果的非確定性
- Two Phase， 爲什麼要兩階段提交
All
最直觀的，往所有節點寫成功就算成功。是一個過程艱辛的正確答案。多個寫操作並行時，部分節點是value=A，部分節點value=B，到底是A還是B呢？
Quorum
好解決。咱們投個票，少數服從多數。關於投票，既然投票，拿了過半的選票數就算勝利了。如果總票數爲偶數，那勢必需要在一個票上相互爭取。既然是爭取就得定個輸贏的規矩。
Rules
最簡單的輸贏規矩是先到先得，佔坑。OK，至此，基本道理咱們都瞭解了。咱們對着協議來說說怎麼玩的。首先給proposal編號，可以理解爲一個Proposal就是一次寫入的申請，有了全局編號意味着就有了順序。如果一個節點（協議成爲Accepter）收到了兩個ID的Proposal：
Same Value
如果兩個寫入者寫入的是同一個值，比如之前提到的數據重發場景。要想達到重發數據也成功的效果，節點就要求可以接收多個Proposa。對應於協議裏面就如果Acceptor發現Proposal的value和已經接受的一致，但是ID比已經接受的大，就也接受這個ID。應該也適用於非重發，但是同時寫入的Value一致的場景。
Uncertainty
同時寫入A和B兩個數據，其中A的ID小於B的ID。結果到底是A還是B呢？按照前面的描述，其實不確定。如果A已經拿到了半數的選票，B就會失敗。但是這種情況對應用來說並非最佳選擇，畢竟有個先後順序。
Two Phase
這塊是最難以理解的，大家都會說有兩個階段。但從不解釋爲啥要拆分成兩個階段（Prepare和 Accept）。我簡述下我的理解，（如果有其他理解或者權威資料的請你通知我）：
- 給ID更大的Proposal多一次機會。第一階段拿到拿到過半票數後，也有可能被ID更大的消息搶走選票；
- 事先詢問。別一股腦去寫入，先問下是否具備寫入條件。如果ID大的哥們已經拿到了過半選票，你還去寫入剩餘的一些戳，其實是沒有必要的，寫了大家也不認，還要再改寫。
- 協助達成所有節點的數據一致，如果ID大的Proposal未被accept，他可以改變自己Proposal的值，發向其他的節點。算法本身並沒有說明這一點。咱們也不去討論如果ID大的寫入失敗了，業務層重新寫入數據的情況，我理解又是一次算法的全過程了。
- 類似Zookeeper，這種同時寫入，更多的是去解決多Master同時存在的情況，通過ID的增加，可以識別出新舊master，從而拒絕舊Master的請求。這種玩法的極端情況情況下，新的Master如果是Prepare成功，Accept失敗，是需要重試的。