一、PAXOS 算法解決的問題
1、PAXOS 算法解決的問題是一個分佈式系統如何就某個值（決議）達成一致。一個典型的場景是，在一個分佈式數據庫系統中，如果各節點的初始狀態一致，每個節點都執行相同的操作序列，那麼他們最後能得到一個一致的狀態。爲保證每個節點執行相同的命令序列，需要在每一條指令上執行一個「一致性算法」以保證每個節點看到的指令一致。一個通用的一致性算法可以應用在許多場景中，是分佈式計算中的重要問題。因此從20世紀80年代起對於一致性算法的研究就沒有停止過。節點通信存在兩種模型（Messages passing）共享內存（Shared memory）和消息傳遞（Messages passing）。Paxos 算法就是一種基於消息傳遞模型的一致性算法。
二、幾個名稱的說明
Proposal（議案），由proposer提出，被aceeptor批准或否決
Value譯（決議），它是議案的內容，一個議案就是一個{編號，決議}對
Accept（批准），表示議案被acceptor批准
Choose（選擇），表示議案“被選擇”，也就是被多數acceptor批准
下面的文章中，”議案、決議、批准、選擇“這4個詞的含義就是按上面的解釋定義的。
三、PAXOS 算法基本定義
3.1、算法中的參與者主要分爲三個角色，同時每個參與者又可兼領多個角色:
1、proposer：提出提案（提案包括案編號和決議）
2、acceptor ：接受(accept)提案;
3、learner： 學習被批准的提案;
3.2、算法一致性的基本語義:
1、決議只有被提出後纔可能被選擇
2、一次Paxos算法的執行實例中，只選擇一個value;（PS：一次Paxos算法的實例是什麼呢，這個一直困擾我）
3、learners只能獲得被選擇的value;
算法的提出者根據上面的基本語義，推出了下面的結論
P1. Acceptor必須批准它接收到的第一個決議。
P2. 如果一個議案{n, v}被選擇，那麼所有被選擇的議案（編號更高）包含的決議都是v。
P2A. 如果一個議案{n, v}被選擇，那麼任何acceptor批准的議案（編號更高）包含的決議都是v。 （P2的進一步強化）
P2B. 如果一個議案{n, v}被選擇，那麼此後，任何proposer提出的議案（編號更高）包含的決議都是v。 （P2A的進一步強化）
P2C. 對於任意的v和n，如果議案{n, v}被提出，那麼存在一個由acceptor的多數派組成的集合S，要麼S中沒有acceptor批准過編號小於n的議案，要麼在S的任何acceptor批准的所有議案（編號小於n）中，v是編號最大的議案的決議。（P2B的進一步表達）
P1A. acceptor可以批准一個編號爲n的議案，當且僅當它沒有迴應過一個編號大於n的prepare請求。（P1的進一步強化）
四、PAXOS 算法的提出（算法分爲2個階段：prepare階段、accept階段）
prepare階段.
a) Proposer：選擇一個議案編號n，向acceptor的多數派發送編號爲n的prepare請求。
b) Acceptor：如果接收到的prepare請求的編號n，大於它已經迴應的任何prepare請求編號，那麼它就回應已經批准的編號最高的議案（如果有的話），並承諾不再回應任何編號小於n的議案；（PS：我認爲這裏已經批准的編號最高的議案是在特定的時間內產生的，至於是怎麼產生的，我會在下面的舉例中說明的，當不在這個特定的時間內，Acceptor就回應沒有問題）
accept階段
a) Proposer：如果收到了多數acceptor對prepare請求（編號爲n）的迴應，它就向這些acceptor發送議案{n, v}的accept請求，其中v是所有迴應中編號最高的議案的決議（Acceptor迴應裏議案中的決議），或者是proposer選擇的值（如果迴應說還沒有議案）。
b) Acceptor：如果收到了議案{n, v}的accept請求，它就批准該議案，除非它已經迴應了一個編號大於n的議案。
五、PAXOS 算法示例
有A1、A2、A3、A4、A5五個議員，當前已經被選擇的議案的最大編號都是n0,
有4個編號n0、n1、n5、n11，並且n0<n1<n5<n11
第一種假設（單個proposer提出議案）
至始至終只有A1 提出議案P1{n1，v1}，那麼很順利，議案P1{n1，v1}被選擇了，A1、A2、A3、A4、A5的最新議案編號都是n1，這時A1、A2、A3、A4、A5被批准的議案爲空（沒有）
A1的議案被學習之後，A5再發起議案P5，很順利，議案P5{n5，v5}被選擇了，A1、A2、A3、A4、A5的最新議案編號都是n5，A1、A2、A3、A4、A5被批准的議案爲空（沒有）
第二種假設（多個proposer提出議案）
A1提出議案P1{n1，v1}、A5提出議案P5{n5，v5} n1<n5
假設A1先提出P1，發送prepare請求給A2、A3（發給A2、A3已經是多數派了），A2，A3發現當前被prepare響應過的編號n0小於n1，並且當前沒有被批准過的議案，所以A2，A3就回復A1沒有問題
A1接收到A2、A3的回覆，就發送accept請求(請求爲議案P1{n1,v1})給A2，A3
1假設：當A2、A3批准了議案P1後，並且議案還沒有被選擇（在多數派批准後到議案確認被選擇這段時間內），這時A5發送編號爲n5的prepare的請求給A4,A3(A5至少需要發送一個prepare請求給A2或者A3以形成多數派，這裏選擇A3)
A4表現： 發現當前被prepare響應過的編號n0<n5，並且當前沒有被批准過的議案，所以就回復A5沒有問題
A3表現: 發現當前被prepare響應過的編號n1<n5，並且當前有被批准過的議案，所以就回復議案P1{n1,v1}給A5，
A5表現： 收到A4，A3的請求，發現A3已經有回覆過的議案了，A5的accpect請求就不會再發送議案P5，而是發送P1{n1，v1}給A3，A4，最後P1被學習了，P5被拋棄了。如果要使A5被學習，只能再發啓另一次prepare請求了。
總結：這個例子中，我們看到A3迴應了已經批准的編號最高的議案給A5，上面我說的特定的時間就是指：在多數派批准後到議案確認被選擇這段時間。我認爲當議案P1被選擇後,A3就不會在發送P1給A5了。即在上面的例子中，1假設改爲當A2、A3批准了議案P1後，並且議案已經被選擇了，那麼這時A5在發送編號爲n5的prepare的請求給A4,A3時，A3就不會回覆P1給A5了，P5最後也就會被學習。
2假設：當A2、A3批准議案P1之前，然後A5發送了prepare的請求給A4,A3，
A4表現：發現當前被prepare響應過的編號n0<n5，並且當前沒有被批准過的議案，所以就回復A5沒有問題
A3表現：發現當前被prepare響應過的編號n1<n5，並且當前還沒有有被批准過的議案，所以就回復A5沒有問題
之後，A1發送accept請求（請求爲議案P1{n1,v1}）給A2，A3，結果A2批准了，A3會拒絕（因爲A3響應過的最大編號已經是n5，n5>n1，滿足P1A條件，就被拒絕了），最後A1的議案沒有被批准，A1可能會重新發送prepare請求（編號爲n11，大於n5）。
總結：這個例子，我們可以發現，paxos算法可能會導致算法循環，比如很容易構造這樣一個場景，兩個proposer輪流提出一系列編號遞增的議案，但是都沒有被選擇。Propoer p選擇議案的編號爲n1，並結束階段1。接着，另外一個proposer q選擇了議案編號n2>n1，並結束階段1。於是p在階段2的accept請求將被忽略，因爲acceptor已經承諾不再批准編號小於n2的議案。於是p再回到階段1並選擇了編號n3 > n2，這又導致q第二階段的accept請求被忽略……，所以提出了leader的概念
關於一次Paxos算法的執行實例我認爲以下找到的解析還是解釋的很好的：
某些資料會把“實例”稱爲“輪”（round），每輪選擇一個決議，但每輪可能會執行多次一致性算法，比如如果主proposer在階段1提出的prepare請求被否決了，那麼它將會選擇新的議案編號，重新提出議案請求，直到議案被多數acceptor批准（消息發送失敗也會導致重傳請求）。引入輪（就是實例啦）這一概念後，可以做到各輪並行運行，同時批准多個決議，互不干涉，更有效率。
六、參考文檔如下：
http://blog.csdn.net/xhh198781/article/details/10949697
http://my.oschina.net/cmffire/blog/11329
http://blog.csdn.net/sparkliang/article/details/5740882
http://blog.csdn.net/m_vptr/article/details/8014220