前言
Paxos 算法如同咱們標題大圖：世界上只有一種一致性算法，就是 Paxos。出自一位 google 大神之口。html
同時，Paxos 也是出名的晦澀難懂，推理過程極其複雜。樓主在嘗試理解 Paxos 算法的過程當中歷經挫折。程序員
今天，樓主不會講推理過程，由於就算是嘗試使用大白話來說，也很是的難懂。固然更不會講數學公式。算法
而是從一個普通 Java 程序員的角度來理解 Paxos 算法。數據庫
1. 什麼是 Paxos 算法
Paxos 算法由圖靈獎得到者 Leslie Lamport 於 1990 年提出的一種基於消息傳遞且具備高度容錯的特性的一致性算法。分佈式
來看看大師的樣貌：google
標準的程序員。。。。spa
Paxos 有點相似咱們以前說的 2PC，3PC，可是解決了他們倆的各類硬傷。該算法在不少大廠都獲得了工程實踐，好比阿里的 OceanBase 的分佈式數據庫，底層就是使用的 paxos 算法。再好比 Google 的 chubby 分佈式鎖也是用的這個算法。可見該算法在分佈式系統中的地位，甚至於，paxos 就是分佈式一致性的代名詞。翻譯
2. Paxos 解決了什麼問題
那麼它解決了什麼問題呢？ 答：解決了一致性問題。3d
什麼是 consensus （一致性）問題？code
在一個分佈式系統中，有一組的 process，每一個 process 均可以提出一個 value，consensus 算法就是用來從這些 values 裏選定一個最終 value。若是沒有 value 被提出來，那麼就沒有 value 被選中；若是有1個 value 被選中，那麼全部的 process 都應該被通知到。
咱們假設一種狀況，在一個集羣環境中，要求全部機器上的狀態是一致的，其中有2臺機器想修改某個狀態，機器 A 想把狀態改成 A，機器 B 想把狀態改成 B，那麼到底聽誰的呢？
有人說，能夠像 2PC，3PC 同樣引入一個協調者，誰先到，聽誰的。
可是若是，協調者宕機了呢？
因此須要對協調者也作備份，也要作集羣。這時候，問題來了，這麼多協調者，聽誰的呢？
Paxos 算法就是爲了解決這個問題而生的！！！ 牛不？
下面，樓主會嘗試用本身的語言配合圖，來解釋使用 Paxos 算法來解決這樣一個相似問題的過程。若是解釋的很差，還請見諒。但樓主不會去寫任何的算法推導過程，若是各位想看，文末有 Paxos 論文連接，和不少大牛寫的推導過程。
開始吧！
3. Paxos 例子說明
樓主這個例子來自中文維基百科，但樓主爲了形象化，輔以圖片解釋，希望不會讓人更迷糊。
例子：
在 Paxos 島上，有A1, A2, A3, A4, A5 5位議員，就稅率問題進行決議。咱們假設幾個場景來解釋：
場景 1.
假設 A1 說：稅率應該是 10%。而此時只有他一我的提這個建議。以下圖：
很完美，沒有任何人和他競爭提案，他的這個提案毫無阻撓的經過了。A2 - A5 都會迴應他：咱們收到了你的提案，等待最終的批准。而 A1 在收到 2 份回覆後，就能夠發佈最終的決議：稅率定位 10%，不用再討論了。
這裏有個注意的地方就是：爲何收到了 2 份回覆就能夠肯定提案了呢？ 答：由於包括他本身，就達到 3 我的了，少數服從多數。 若是各位據說過鴿籠原理/抽屜原理，就明白個大概了。有人說，鴿籠原理/抽屜原理就是 Paxos 的核心思想。
場景 2：
如今咱們假設在 A1 提出 10% 稅率提案的同時, A5 決定將稅率定爲 20%，若是這個提案要經過侍從送到其餘議員的案頭，A1 的草案將由 4 位侍從送到 A2-A5 那裏。可是侍從不靠譜（表明分佈式環境不靠譜），負責 A2 和 A3 的侍從順利送達，而負責 A4 和 A5 的侍從則開溜了！
而 A5 的草案則送到了 A4 和 A3 的手中。
如今，A1 ，A2，A3 收到了 A1 的提案，A3，A4， A5 收到 A5 的提案，按照 Paxos 的協議，A1，A2，A4，A5 4個侍從將接受他們的提案，侍從拿着回覆：我已收到你的提案，等待最終批准 回到提案者那裏。
而 A3 的行爲將決定批准哪個。
當 A3 同時收到了 A1 和 A5 的請求，該如何抉擇呢？不一樣的抉擇將會致使不一樣的結果。
有 3 種狀況，咱們分析一下：
場景2：狀況一
假設 A1 的提案先送到 A3 那裏，而且 A3 接受了該提案並回復了侍從。這樣，A1 加上 A2 加上 A3，構成了多數派，成功肯定了稅率爲 10%。 而 A5 的侍從因爲路上喝酒喝多了，晚到了一天，等他到了，稅率已經肯定了，A3 回覆 A5：兄弟，你來的太晚了，稅率已經定好了，不用折騰了，聽 A1 的吧。
以下圖：
場景2：狀況二
依然假設 A1 的提案先送到 A3 處，可是此次 A5 的侍從不是放假了，只是中途耽擱了一會。此次, A3 依然會將"接受"回覆給 A1 .可是在決議成型以前它又收到了 A5 的提案。這時協議根據 A5 的身份地位有兩種處理方式，但結果相同。
- 當 A5 地位很高，例如 CEO，就回復 A5：
我已收到您的提案，等待最終批准，可是您以前有人提出將稅率定爲10%,請明察。 - 當 A5 沒地位，普通碼農一個，直接不回覆。等待 A1 廣播：
稅率定爲 10% 啦！！！
以下圖：
場景2：狀況三
在這個狀況中，咱們將看見，根據提案的時間及提案者的權勢決定是否應答是有意義的。在這裏，時間和提案者的權勢就構成了給提案編號的依據。這樣的編號符合"任何兩個提案之間構成偏序"的要求。
A1 和 A5 一樣提出上述提案，這時 A1 能夠正常聯繫 A2 和 A3，A5 也能夠正常聯繫這兩我的。此次 A2 先收到 A1 的提案; A3 則先收到 A5 的提案。而 A5 更有地位。
在這種狀況下，已經回答 A1 的 A2 發現有比 A1 更有權勢的 A5 提出了稅率 20% 的新提案，因而回復A5說：我已收到您的提案，等待最終批准。
而回復 A5 的 A3 發現新的提案者A1是個小人物，沒地位不予應答。
此時，A5 獲得了 A2，A3 的回覆，因而 A5 說：稅率定爲 20%，別再討論了。
那 A4 呢？ A4 因爲睡過頭了，迷迷糊糊的說：現有的稅率是什麼? 若是沒有決定，則建議將其定爲 15%.
這個時候，其餘的議員就告訴他：哥們，已經定爲 20% 了，別折騰了。洗洗繼續睡吧。
整個過程以下圖：
4. 總結
從上面的例子能夠看出：這個 Paxos 協議/算法 就是少數服從多數，標準的 鴿籠原理/抽屜原理，同時，還會根據議員的身份來判斷是否須要應答，這個身份其實就是一個編號，是爲了防止出現活性致使死循環。
注意：這一切都是在沒有 拜占庭將軍 問題的基礎上創建的，即消息不會被篡改（由於分佈式大多在局域網中）。
Paxos 的目標：保證最終有一個提案會被選定，當提案被選定後，其餘議員最終也能獲取到被選定的提案。
Paxos 協議用來解決的問題能夠用一句話來簡化： 將全部節點都寫入同一個值，且被寫入後再也不更改。
引用
如何淺顯易懂地解說 Paxos 的算法？ 圖解 Paxos 一致性協議 分佈式系列文章——Paxos算法原理與推導 Paxos算法 維基百科，自由的百科全書 Paxos Made Simple【翻譯】 The Part-Time Parliament(Paxos算法中文翻譯)