解決的問題
如上圖所示，對於一個分佈式系統，客戶端同時發送一個數據，比如a,每個客戶端a的值是不一樣的，那麼怎麼保證服務器集羣的各個節點a的值是保持一致的呢，Paxos就是解決這個問題的
上圖有引入客戶端，只是爲了便於理解這個場景，本質是節點之間的數據共識，下面的都是節點
Paxos三種角色
Proposers：提議者，提供一個提議
Acceptors ：接受者，接受數據，對提議進行投票，保存提議的值
Learners：學習者，保存最終投票的結果，不參與投票
每個節點可以承擔多個角色
Paxos算法分兩個階段進行
對於每個提議着提議的值，都給其一個編號，類似[n,v]存儲，n表示編號，v表示提議的值
對於接受者，如果它已經有一個值，那麼它只接受比這個值的編號大的提議者提交的值
大多數場景中，提議者都是服務其中接收到數據的節點
Paxos是兩階段提交
分爲prepare和accept
第一階段:prepare
Server作爲提議者：
注意：提議階段不會發送數據的，只會發送編號
Server1分別向Server2和Server3提交編號爲1的提議
Server2接受Server1的提議，回覆promise
Server3因爲已經有編號爲2的提議，比編號1大，忽略此提議，回覆reject
Server3：作爲提議者
第一階段：prepare
Server3分別向Server1和Server2提交編號爲2的提議
Sever2接受Serve3的提議，因爲請求提議的編號比之前獲得提議編號大，回覆promise
Server1接受Server3的提議，因爲請求提議的編號比自身的提議編號大，回覆promise
第二階段：accept階段
從第一階段可以看到，server1收到了一個promise，Server3收到了兩個promise，
只有Server3收到了超過半數的promise，所以在accept階段，只需要Server3發送accept就可以了
所以最終數據就是2，當然在accept階段，有可能還有其他的proposer提交提議，方法和前面相同，比較提議的編號，如果proposer提議的編號編號比accepter的編號小，則accepter直接返回reject，如果比accepter大,那麼accepter返回promise，並且帶上accpet的數據(n,v),Accepter取最大的n對應的v就可以了。