上一篇講述了兩個經典的分佈式一致性協議（2PC、3PC），這篇博客開始講解paxos協議，paxos算法是目前公認的解決分佈式一致性問題最有效的算法之一。
1、起源
拜占庭將軍問題
提及paxos協議的起源，首先得說說這個“拜占庭將軍”問題，這個問題實際上是分佈式數據一致性問題的一個抽象故事。
故事中的通訊員就是所謂的通信信道，拜占庭故事的結局就是在這種情況下將軍之間不可能接收到一個完全正確的決定。也就是說在分佈式系統中，試圖在異步系統和不可靠通道上達到一致性狀態是不可能的。
有人就會問，既然是不可能，那研究的分佈式一致性協議有啥用呢？
——實際工程上，由於信道編碼糾錯等機制，我們可以假設所有信道傳輸的消息是完整的，是沒有被篡改過的，也就是故事中的通訊員不能篡改消息。考慮到這種實際場景下，我們研究的分佈式一致性協議纔有用處。
那麼當信道不存在篡改的情況，該場景下又是如何解決上述問題的呢？
——lamport在1990提出了paxos算法解決上述問題。
lamport將上述的問題設想了這麼一個場景：
（多提一句，據說該場景是考古工作者發現真是會議手稿推測的，並不是lamport憑空設想的）
這個場景就具體代表了分佈式系統中，多個節點中，數據如何保持一致性，多個節點最終對於某個數據值能夠保證一致，也就是對應場景中法令是唯一有效的，不衝突。
如何解決上述的正確法令的產生，paxos算法。
2、算法陳述
paxos算法有着嚴格的數據公式的證明，但太過於複雜，能以理清，這裏我們不在討論具體的證明過程，只給出paxos算法是如何從衆多提案中最終選擇一個統一提案的過程。
首先和上述的故事場景類似，存在一個提出者（Proposer）和接收者（Acceptor），同樣，整個選舉的過程也分爲兩個階段：
通過上述的兩個階段，即可保證最終可以得到一個統一的提案。
有人會問，現在知道了這個paxos算法，但是到底怎麼用，是怎麼一回事呢？？
——在設計分佈式系統的時候，我們可以將每個節點向管理節點選舉時，按照上述提交者的步驟，將每個消息就加上對應的編號，同樣，管理節點接收到信息，也按照上述的步驟進行返回，最後即可按照此算法就多個節點同一個數據值達到一致。
3、paxos算法優缺點
paxos算法的優點很明顯，按照此方法可以對多個數據值達到一致，收斂較好。
paxos算法的缺點即存在活性問題：考慮到一種極端的情況下，有兩個proposer依次提出了一系列編號遞增的議案，但是最終paxos無法形成最終的議案。具體場景如下：
沒錯，在這種情況下，提案只會不斷的死循環，提出，被拋棄，再次提出，被拋棄。。。無法保持活性。。。
解決辦法：
爲了保持活性，避免上述的問題，就必須選擇一個主Proposer，並規定只能由主Proposer才能提出議案，只有主能提出議案，那麼就算主被拋棄了，下次也會提出更高議案，而其他非主不能再次提出更高的議案，這樣就不會陷入死循環中，從而避免了上述的問題。
總結：
通過選擇一個主Proposer，並規定只能由主Proposer才能提出議案，整個paxos算法就可以保持活性。
參考：
《從paxos到zookeeper》