Paxos算法

Paxos算法

 

 參考：

http://www.cnblogs.com/shangxiaofei/p/5206657.html

https://blog.csdn.net/cnh294141800/article/details/53768464

http://www.cnblogs.com/shangxiaofei/p/5207218.html

 

 

分佈式事務一致性協議paxos通俗理解

維基的簡介：Paxos算法是萊斯利·蘭伯特（Leslie Lamport，就是 LaTeX 中的"La"，此人如今在微軟研究院）於1990年提出的一種基於消息傳遞且具備高度容錯特性的一致性算法。

Paxos算法目前在Google的Chubby、MegaStore、 Spanner等系統中獲得了應用，Hadoop中的ZooKeeper也使用了Paxos算法，在上面的各個系統中，使用的算法與Lamport提出的 原始Paxos並不徹底同樣，這個之後再慢慢分析。本博文的目的是，如何讓一個小白在半個小時以內理解Paxos算法的思想。小白可能對數學不感興趣，對 分佈式的複雜理論不熟悉，只是一個入門級程序員。之因此想寫這篇博文，是由於本身看了網上不少介紹Paxos算法的文章，以及博客，包括Lamport的論文，感受仍是難以理解，大多過於複雜，本人一直認爲，複雜高深的理論背後必定基於一些通用的規律，而這些通用的規律在生活中其實咱們早就遇到過，甚至用過。因此，咱們先忽略Paxos算法自己，從生活中的小事開始談起。

 假若有一羣驢友要決定中秋節去旅遊，這羣驢友分佈在全國各地，假定一共25個 人，分別在不一樣的省，要決定到底去拉薩、昆明、三亞等等哪一個地點（會合時間中秋節已經定了，此時須要決定旅遊地）。最直接的方式固然就是建一個QQ羣，大 家都在裏面投票，按照少數服從多數的原則。這種方式相似於「共享內存」實現的一致性，實現起來簡單，但Paxos算法不是這種場景，由於Paxos算法認 爲這種方式有一個很大的問題，就是QQ服務器掛掉怎麼辦？Paxos的原則是容錯性必定要很強。因此，Paxos的場景相似於這25我的相互之間只能發短 信，須要解決的核心問題是，哪怕任意的一部分人（Paxos的目的實際上是少於半數的人）「失聯」了，其它人也可以在會合地點上達成一致。好了，怎麼設計 呢？

這25我的找了另外的5我的（固然這5我的能夠從25我的中選，這裏爲了描述方 便，就單拿出另外5我的），好比北京、上海、廣州、深圳、成都的5我的，25我的都給他們發短信，告訴本身傾向的旅遊地。這5我的相互之間能夠並不通訊， 只接受25我的發過來的短信。這25我的咱們稱爲驢友，那5我的稱爲隊長。

先來看驢友的邏輯。驢友能夠給任意5個隊長都發短信，發短信的過程分爲兩個步驟：

第一步（申請階段）：詢問5個隊長，試圖與隊長溝通旅遊地。由於每一個隊長一直會收 到不一樣驢友的短信，不能跟多個驢友一塊兒溝通，在任什麼時候刻只能跟一個驢友溝通，按照什麼原則才能作到公平公正公開呢？這些短信都帶有發送時間，隊長採用的原 則是贊成與短信發送時間最新的驢友溝通，若是出現了更新的短信，則與短信更 新的驢友溝通。總之，做爲一個有話語權的人，只有時刻保持傾聽最新的呼聲，才能作出最明智的選擇。在驢友發出短信後，等着隊長。某些隊長可能會說，你這條 短信太老了，我不與你溝通；有些隊長則可能返回說，你的短信是我收到的最新的，我贊成跟你溝通。對於後面這些隊長，還得返回本身決定的旅遊地。關於隊長是 怎麼決定旅遊地的，後面再說。

對於驢友來講，第一步必須至少有半數以上隊長都贊成溝通了，才能進入下一步。不然，你連溝通的資格都沒有，一直在那兒狂發吧。你發的短信更新，你得到溝通權的可能性才更大。。。。。。

由於至少有半數以上隊長（也就是3個隊長以上）贊成，你才能與隊長們進行實質性的溝通，也就是進入第二步；而隊長在任什麼時候候只能跟1個驢友溝通，因此，在任什麼時候候，不可能出現兩個驢友都達到了這個狀態。。。固然，你能夠經過狂發短信把溝通權搶了。。。。

對於得到溝通權的那個驢友（稱爲A），那些隊長會給他發送他們本身決定的旅遊地（也可能都尚未決定）。能夠看出，各個隊長是本身決定旅遊地的，隊長之間無需溝通。

第二步（溝通階段）：這個幸運的驢友收到了隊長們給他發的旅遊地，可能有幾種狀況：

第一種狀況：跟A溝通的隊長們（不必定是所有5個隊長，可是半數以上）所有都尚未決定到底去那兒旅遊，此時驢友A心花盛開，給這些隊長髮第二條短信，告訴他們本身但願的旅遊地（好比馬爾代夫）；

可能會收到兩種結果：一是半數以上隊長都贊成了，因而代表A建議的馬爾代夫被半數以上隊長都 贊成了，整個決定過程完畢了，其它驢友早晚會知道這個消息的，A先去收拾東西準備去馬爾代夫；除此以外，代表失敗。可能隊長出故障了，好比某個隊長在跟女 朋友打電話等等，也可能被其它驢友搶佔溝通權了（由於隊長喜新厭舊嘛，只有要更新的驢友給本身發短信，本身就與新人溝通，A的建議隊長不一樣意）等等。無論 怎麼說，苦逼的A還得從新從第一步開始，從新給隊長們發短信申請。

第二種狀況：至少有一個隊長已經決定旅遊地了，A可能會收到來自不一樣隊長決定的多 個旅遊地，這些旅遊地是不一樣隊長跟不一樣驢友在不一樣時間上作出的決定，那麼，A會先看一下，是否是有的旅遊地已經被半數以上隊長贊成了（好比3個隊長都贊成 去三亞，1個贊成去昆明，另一個沒搭理A），若是出現了這種狀況，那就別扯了，說明整個決定過程已經達成一致了，收拾收拾準備去三亞吧，結束了；若是都 沒有達到半數以上（好比1個贊成去昆明，1個贊成去三亞，2個贊成去拉薩，1個沒搭理我），A做爲一個高素質驢友，也不按照本身的意願亂來了（Paxos 的關鍵所在，後者認同前者，不然整個決定過程永無止境），雖然本身原來可能想去馬爾代夫等等。就給隊長們發第二條短信的時候，告訴他們本身但願的旅遊地， 就是本身收到的那堆旅遊地中最新決定的那個。（好比，去昆明那個是北京那個隊長前1分鐘決定的，去三亞的決定是上海那個隊長1個小時以前作出來的，因而頂 昆明）。驢友A的想法是，既然有隊長已經作決定了，那我就乾脆頂最新那個決定。

從上面的邏輯能夠看出，一旦某個時刻有半數以上隊長贊成了某個地點好比昆明，緊跟着後面的驢友B繼續發短信時，若是得到溝通權，由於半數以上隊長都贊成與B溝通了，說明B收到了來自半數以上隊長髮過來的消息，B必然會收到至少一個隊長給他發的昆明這個結果（不然說明半數以上隊長都沒有贊成昆明這個結果，這顯然與前面的假設矛盾），B因而會頂這個最新地點，不會更改，由於後面的驢友都會頂昆明，所以贊成昆明的隊長愈來愈多，最終必然達成一致。

看完了驢友的邏輯，那麼隊長的邏輯是什麼呢？

隊長的邏輯比較簡單。

在申請階段，隊長只會選擇與最新發申請短信的驢友溝通，隊長知道本身接收到最新短信的時間，對於更老的短信，隊長不會搭理；隊長贊成溝通了的話，會把本身決定的旅遊地（或者還沒決定這一信息）發給驢友。

在溝通階段，驢友C會把本身但願的旅遊地發過來（同時會附加上本身申請短信的時 間，好比3分鐘前），因此隊長要檢查一下，若是這個時間（3分鐘前）確實是當前本身最新接收到申請短信的時間（說明這段時間沒有驢友要跟本身溝通），那 麼，隊長就贊成驢友C的這個旅遊地了（好比昆明，哪怕本身1個小時前已經作過去三亞的決定，誰讓C更新呢，因而更新爲昆明）；若是不是最新的，說明這3分 鍾內又有其它驢友D跟本身申請了，由於本身是個喜新厭舊的傢伙，贊成與D溝通了，因此驢友C的決定本身不會贊成，等着D一下子要發過來的決定吧。

 

Paxos的基本思想大體就是上面的過程。能夠看出，其實驢友的策略纔是Paxos的關鍵。讓咱們來跟理論對應一下。

Paxos主要用於保證分佈式存儲中副本（或者狀態）的一致性。副本要保持一致， 那麼，全部副本的更新序列就要保持一致。由於數據的增刪改查操做通常都存在多個客戶端併發操做，到底哪一個客戶端先作，哪一個客戶端後作，這就是更新順序。如 果不是分佈式，那麼能夠利用加鎖的方法，誰先申請到鎖，誰就先操做。可是在分佈式條件下，存在多個副本，若是依賴申請鎖+副本同步更新完畢再釋放鎖，那麼 須要有分配鎖的這麼一個節點（若是是多個鎖分配節點，那麼又出現分佈式鎖管理的需求，把鎖給哪個客戶端又成爲一個難點），這個節點又成爲單點，豈不是可 靠性不行了，失去了分佈式多副本的意義，同時性能也不好，另外，還會出現死鎖等狀況。

因此，說來講去，只有解決分佈式條件下的一致性問題，彷佛才能解決本質問題。

如上面的例子，Paxos解決這一問題利用的是選舉，少數服從多數的思想，只要 2N+1個節點中，有N個以上贊成了某個決定，則認爲系統達到了一致，而且按照Paxos原則，最終理論上也達到了一致，不會再改變。這樣的話，客戶端不 必與全部服務器通訊，選擇與大部分通訊便可；也無需服務器都所有處於工做狀態，有一些服務器掛掉，只有保證半數以上存活着，整個過程也能持續下去，容錯性 至關好。所以，之前看有的博客說在部署ZooKeeper這種服務的時候，須要奇數臺機器，這種說法固然有必定來源背景，好比若是是5臺，那麼任意客戶端 與任意其中3臺達成一致就至關於投票結束，不過6臺有何不可？只是此時須要與4臺以上達成一致。

Paxos中的Acceptor就至關於上面的隊長，Proposer就至關於上 面的驢友，epoch編號就至關於例子中申請短信的發送時間。關於Paxos的正式描述已經不少了，這裏就不復述了，關於Paxos正確性的證實，由於比 較複雜，之後有時間再分析。另外，Paxos最消耗時間的地方就在於須要半數以上贊成溝通了才能進入第二步，試想一下，一開始，全部驢友就給隊長狂發短 信，每一個隊長收到的最新短信的是不一樣驢友，這樣，就難以達到半數以上都贊成與某個驢友溝通的狀態，爲了減少這個時間，Paxos還有Fast Paxos的改進等等，有空再分析。

卻是有一些問題能夠思考一下：在Paxos以前，或者說除了Chubby，ZooKeeper這些系統，其它分佈式系統一樣面臨這樣的一致性問題，好比HDFS、分佈式數據庫、Amazon的Dynamo等等，解決思路又不一樣，有空再進行對比分析。

最後談談一致性這個名詞。

關於Paxos說的一致性，我的理解是指冗餘副本（或狀態等，但都是由於存在冗餘）的一致性。這與關係型數據庫中ACID的一致性說的不是一個東西。在關係數據庫裏，能夠連副本都沒有，何談副本的一致性？按照經典定義，ACID中的C指的是在一個事務中，事務執行的結果必須是使數據庫從一個一致性狀態變到另外一個一致性狀態。那麼，什麼又是一致性狀態呢，這跟業務約束有關係，好比經典的轉帳事務，事務處理完畢後，不能出現一個帳戶錢被扣了，另外一個帳戶的錢沒有增長的狀況，若是二者加起來的錢仍是等於轉帳前的錢，那麼就是一致性狀態。

從不少博文來看，對這兩種一致性每每混淆起來。另外，CAP原則裏面所說的一致 性，我的認爲是指副本一致性，與Paxos裏面的一致性接近。都是處理「由於冗餘數據的存在而須要保證多個副本保持一致」的問題，NoSQL放棄的強一致 性也是指副本一致性，最終一致性也是指副本達到徹底相同存在必定延時。

固然，若是數據庫自己是分佈式的，且存在冗餘副本，則除了解決事務在業務邏輯上的一致性問題外，同時須要解決副本一致性問題，此時能夠利用Paxos協議。但解決了副本一致性問題，還不能徹底解決業務邏輯一致性；若是是分佈式數據庫，但並不存在副本的狀況，事務的一致性須要根據業務約束進行設計。

另外，談到Paxos時，還會涉及到拜占庭將軍問題，它指的是在存在消息丟失的不 可靠信道上試圖經過消息傳遞的方式達到一致性是不可能的。Paxos自己就是利用消息傳遞方式解決一致性問題的，因此它的假定是信道必須可靠，這裏的可 靠，主要指消息不會被篡改。消息丟失是容許的。

關於一致性、事務的ACID，CAP，NoSQL等等問題，之後再詳細分析。本文的描述也許可能存在一些舉例不太恰當的地方，若是錯誤，歡迎批評指正。

 

 

 

Paxos協議超級詳細解釋+簡單實例

Paxos算法的目的

Paxos算法的目的是爲了解決分佈式環境下一致性的問題。

    多個節點併發操縱數據，如何保證在讀寫過程當中數據的一致性，而且解決方案要能適應分佈式環境下的不可靠性（系統如何就一個值達到統一）

Paxos的兩個組件

Proposer

提議發起者，處理客戶端請求，將客戶端的請求發送到集羣中，以便決定這個值是否能夠被批准。

Acceptor

提議批准者，負責處理接收到的提議，他們的回覆就是一次投票。會存儲一些狀態來決定是否接收一個值

Paxos有兩個原則

1)安全原則---保證不能作錯的事

a） 針對某個實例的表決只能有一個值被批准，不能出現一個被批准的值被另外一個值覆蓋的狀況；(假設有一個值被多數Acceptor批准了，那麼這個值就只能被學習)

b） 每一個節點只能學習到已經被批准的值，不能學習沒有被批准的值。

2)存活原則---只要有多數服務器存活而且彼此間能夠通訊，最終都要作到的下列事情：

a）最終會批准某個被提議的值；

b）一個值被批准了，其餘服務器最終會學習到這個值。

Paxos具體流程圖

 

 

第一階段（prepare）

1）.獲取一個proposal number, n；

2）.提議者向全部節點廣播prepare(n)請求；

3）.接收者（Acceptors比較善變，若是還沒最終承認一個值，它就會不斷認同提案號最大的那個方案）比較n和minProposal，若是n>minProposal,表示有更新的提議minProposal=n；若是此時該接受者並無承認一個最終值，那麼承認這個提案，返回OK。若是此時已經有一個accptedValue, 將返回(acceptedProposal,acceptedValue)；

4）.提議者接收到過半數請求後，若是發現有acceptedValue返回，表示有承認的提議，保存最高acceptedProposal編號的acceptedValue到本地

 

第二階段(Accept)

5）廣播accept(n,value)到全部節點；

6).接收者比較n和minProposal，若是n>=minProposal,則acceptedProposal=minProposal=n，acceptedValue=value，本地持久化後，返回；

不然，拒絕而且返回minProposal

7).提議者接收到過半數請求後，若是發現有返回值>n，表示有更新的提議，跳轉1（從新發起提議）；不然value達成一致。

 

 

Paxos議案ID生成算法

       在Google的Chubby論文中給出了這樣一種方法：假設有n個proposer，每一個編號爲ir(0<=ir<n)，proposal編號的任何值s都應該大於它已知的最大值，而且知足：

     s %n = ir    =>     s = m*n + ir

    proposer已知的最大值來自兩部分：proposer本身對編號自增後的值和接收到acceptor的拒絕後所獲得的值。

例：  以3個proposer P一、P二、P3爲例，開始m=0,編號分別爲0，1，2。

1） P1提交的時候發現了P2已經提交，P2編號爲1 >P1的0，所以P1從新計算編號：new P1 = 1*3+1 = 4；

2） P3以編號2提交，發現小於P1的4，所以P3從新編號：new P3 = 1*3+2 = 5。

 

Paxos原理

任意兩個法定集合，一定存在一個公共的成員。該性質是Paxos有效的基本保障

 

活鎖

     當某一proposer提交的proposal被拒絕時，多是由於acceptor 承諾返回了更大編號的proposal，所以proposer提升編號繼續提交。 若是2個proposer都發現本身的編號太低轉而提出更高編號的proposal，會致使死循環，這種狀況也稱爲活鎖。

       好比說當此時的 proposer1提案是3, proposer2提案是4, 但acceptor承諾的編號是5，那麼此時proposer1,proposer2 都將提升編號假設分別爲6,7，並試圖與accceptor鏈接，假設7被接受了，那麼提案5和提案6就要從新編號提交，從而不斷死循環。

 

異常狀況——持久存儲

     在算法執行的過程當中會產生不少的異常狀況：proposer宕機，acceptor在接收proposal後宕機，proposer接收消息後宕機，acceptor在accept後宕機，learn宕機，存儲失敗，等等。

     爲保證paxos算法的正確性，proposer、aceptor、learn都實現持久存儲，以作到server恢復後仍能正確參與paxos處理。

    propose存儲已提交的最大proposal編號、決議編號（instance id）。

    acceptor存儲已承諾（promise）的最大編號、已接受（accept）的最大編號和value、決議編號。

    learn存儲已學習過的決議和編號

具體實例：

假設的3軍問題

 

1） 1支紅軍在山谷裏紮營，在周圍的山坡上駐紮着3支藍軍；

2） 紅軍比任意1支藍軍都要強大；若是1支藍軍單獨做戰，紅軍勝；若是2支或以上藍軍同時進攻，藍軍勝；

3） 三支藍軍須要同步他們的進攻時間；但他們唯一的通訊媒介是派通訊兵步行進入山谷，在那裏他們可能被俘虜，從而將信息丟失；或者爲了不被俘虜，可能在山谷停留很長時間；

4） 每支軍隊有1個參謀負責提議進攻時間；每支軍隊也有1個將軍批准參謀提出的進攻時間；很明顯，1個參謀提出的進攻時間須要得到至少2個將軍的批准纔有意義；

5） 問題：是否存在一個協議，可以使得藍軍同步他們的進攻時間？

 

接下來以兩個假設的場景來演繹BasicPaxos；參謀和將軍須要遵循一些基本的規則

1） 參謀以兩階段提交（prepare/commit）的方式來發起提議，在prepare階段須要給出一個編號；

2） 在prepare階段產生衝突，將軍以編號大小來裁決，編號大的參謀勝出；

3） 參謀在prepare階段若是收到了將軍返回的已接受進攻時間，在commit階段必須使用這個返回的進攻時間；

兩個參謀前後提議的場景

 

1） 參謀1發起提議，派通訊兵帶信給3個將軍，內容爲（編號1）；

2） 3個將軍收到參謀1的提議，因爲以前尚未保存任何編號，所以把（編號1）保存下來，避免遺忘；同時讓通訊兵帶信回去，內容爲（ok）；

3） 參謀1收到至少2個將軍的回覆，再次派通訊兵帶信給3個將軍，內容爲（編號1，進攻時間1）；

4） 3個將軍收到參謀1的時間，把（編號1，進攻時間1）保存下來，避免遺忘；同時讓通訊兵帶信回去，內容爲（Accepted）；

5） 參謀1收到至少2個將軍的（Accepted）內容，確認進攻時間已經被你們接收；

 

6） 參謀2發起提議，派通訊兵帶信給3個將軍，內容爲（編號2）；

7） 3個將軍收到參謀2的提議，因爲（編號2）比（編號1）大，所以把（編號2）保存下來，避免遺忘；又因爲以前已經接受參謀1的提議，所以讓通訊兵帶信回去，內容爲（編號1，進攻時間1）；

8） 參謀2收到至少2個將軍的回覆，因爲回覆中帶來了已接受的參謀1的提議內容，參謀2所以再也不提出新的進攻時間，接受參謀1提出的時間；

兩個參謀交叉提議的場景

 

 

1） 參謀1發起提議，派通訊兵帶信給3個將軍，內容爲（編號1）；

2） 3個將軍的狀況以下

a) 將軍1和將軍2收到參謀1的提議，將軍1和將軍2把（編號1）記錄下來，若是有其餘參謀提出更小的編號，將被拒絕；同時讓通訊兵帶信回去，內容爲（ok）；

b) 負責通知將軍3的通訊兵被抓，所以將軍3沒收到參謀1的提議；

 

3） 參謀2在同一時間也發起了提議，派通訊兵帶信給3個將軍，內容爲（編號2）；

4） 3個將軍的狀況以下

a) 將軍2和將軍3收到參謀2的提議，將軍2和將軍3把（編號2）記錄下來，若是有其餘參謀提出更小的編號，將被拒絕；同時讓通訊兵帶信回去，內容爲（ok）；

b) 負責通知將軍1的通訊兵被抓，所以將軍1沒收到參謀2的提議；

 

5） 參謀1收到至少2個將軍的回覆，再次派通訊兵帶信給有答覆的2個將軍，內容爲（編號1，進攻時間1）；

6） 2個將軍的狀況以下

a) 將軍1收到了（編號1，進攻時間1），和本身保存的編號相同，所以把（編號1，進攻時間1）保存下來；同時讓通訊兵帶信回去，內容爲（Accepted）；

b) 將軍2收到了（編號1，進攻時間1），因爲（編號1）小於已經保存的（編號2），所以讓通訊兵帶信回去，內容爲（Rejected，編號2）；

 

7） 參謀2收到至少2個將軍的回覆，再次派通訊兵帶信給有答覆的2個將軍，內容爲（編號2，進攻時間2）；

8） 將軍2和將軍3收到了（編號2，進攻時間2），和本身保存的編號相同，所以把（編號2，進攻時間2）保存下來，同時讓通訊兵帶信回去，內容爲（Accepted）；

9） 參謀2收到至少2個將軍的（Accepted）內容，確認進攻時間已經被多數派接受；

 

10） 參謀1只收到了1個將軍的（Accepted）內容，同時收到一個（Rejected，編號2）；參謀1從新發起提議，派通訊兵帶信給3個將軍，內容爲（編號3）；

11） 3個將軍的狀況以下

a) 將軍1收到參謀1的提議，因爲（編號3）大於以前保存的（編號1），所以把（編號3）保存下來；因爲將軍1已經接受參謀1前一次的提議，所以讓通訊兵帶信回去，內容爲（編號1，進攻時間1）；

b) 將軍2收到參謀1的提議，因爲（編號3）大於以前保存的（編號2），所以把（編號3）保存下來；因爲將軍2已經接受參謀2的提議，所以讓通訊兵帶信回去，內容爲（編號2，進攻時間2）；

c) 負責通知將軍3的通訊兵被抓，所以將軍3沒收到參謀1的提議；

12） 參謀1收到了至少2個將軍的回覆，比較兩個回覆的編號大小，選擇大編號對應的進攻時間做爲最新的提議；參謀1再次派通訊兵帶信給有答覆的2個將軍，內容爲（編號3，進攻時間2）；

13） 將軍1和將軍2收到了（編號3，進攻時間2），和本身保存的編號相同，所以保存（編號3，進攻時間2），同時讓通訊兵帶信回去，內容爲（Accepted）；

14） 參謀1收到了至少2個將軍的（accepted）內容，確認進攻時間已經被多數派接受；

 

 

 

分佈式事務一致性協議paxos的分析

最近研究paxos算法，看了許多相關的文章，概念仍是很模糊，以爲仍是沒有掌握paxos算法的精髓，因此花了3天時間分析了libpaxos3的全部代碼，此代碼能夠從https://bitbucket.org/sciascid/libpaxos 下載。對paxos算法有初步瞭解以後，再看此文的效果會更好；若是你也想分析libpaxos3的話，此文應該會對你有不小幫助；關於paxos的歷史這裏很少作介紹，關於描述paxos算法寫的最好的一篇文章應該就是維基百科了，地址戳這裏：http://zh.wikipedia.org/zh-cn/Paxos%E7%AE%97%E6%B3%95

 

在paxos算法中，分爲4種角色：

  Proposer ：提議者

  Acceptor：決策者

  Client：產生議題者

  Learner：最終決策學習者

上面4種角色中，提議者和決策者是很重要的，其餘的2個角色在整個算法中應該算作 打醬油的，Proposer就像Client的使者，由Proposer使者拿着Client的議題去向Acceptor提議，讓Acceptor來決 策。這裏上面出現了個新名詞：最終決策。如今來系統的介紹一下paxos算法中全部的行爲：

Proposer提出議題
Acceptor初步接受 或者 Acceptor初步不接受
若是上一步Acceptor初步接受則Proposer再次向Acceptor確認是否最終接受
Acceptor 最終接受 或者Acceptor 最終不接受
上面Learner最終學習的目標是Acceptor們最終接受了什麼議題？注意，這裏是向全部Acceptor學習，若是有多數派個Acceptor最終接受了某提議，那就獲得了最終的結果，算法的目的就達到了。畫一幅圖來更加直觀：
 爲何須要3個Acceptor？由於Acceptor必須是最少大於等於3個，而且必須是奇數個，由於要造成多數派嘛，若是是偶數個，好比4個，2個接受2個不接受，互不相讓，無法搞下去了。爲何是3個Proposer？ 其實無所謂是多少個了，1~n 均可以的；若是是1個proposer，毫無競爭壓力，很順利的完成2階段提交，Acceptor們最終批准了事。若是是多個proposer就比較複雜了，請繼續看。 上面的圖中是畫了不少節點的，每一個節點須要一臺機器麼？答案是不須要的，上面的圖 是邏輯圖，物理中，能夠將Acceptor和Proposer以及Client放到一臺機器上，只是使用了不一樣的端口號罷了，Acceptor們啓動不一樣 端口的TCP監聽，Proposer來主動鏈接便可；徹底能夠將Client、Proposer、Acceptor、Learner合併到一個程序裏面； 這裏舉一個例子：好比開發一個JOB程序，JOB程序部署在多臺服務器上(數量爲奇數)，這些JOB有可能同時處理一項任務，如今使用paxos算法讓這 些JOB本身來商量由誰(哪臺機器)來處理這項任務，這樣JOB程序裏就須要包含Client、Proposer、Acceptor、Learner這4 大功能，而且須要配置其餘JOB服務器的IP地址。再舉一個例子，zookeeper經常用來作分佈式事務鎖。Zookeeper所 使用的zad協議也是相似paxos協議的。全部分佈式自協商一致性算法都是paxos算法的簡化或者變種。Client是使用zookeeper服務的 機器，Zookeeper自身包含了Acceptor, Proposer, Learner。Zookeeper領導選舉就是paxos過程，還有Client對Zookeeper寫Znode時，也是要進行Paxos過程的，因 爲不一樣Client可能鏈接不一樣的Zookeeper服務器來寫Znode，到底哪一個Client才能寫成功？須要依靠Zookeeper的paxos保 證一致性，寫成功Znode的Client天然就是被最終接受了，Znode包含了寫入Client的IP與端口，其餘的Client也能夠讀取到這個 Znode來進行Learner。也就是說在Zookeeper自身包含了Learner(由於Zookeeper爲了保證自身的一致性而會進行領導選 舉，因此須要有Learner的內部機制，多個Zookeeper服務器之間須要知道如今誰是領導了)，Client端也能夠 Learner，Learner是廣義的。 如今經過一則故事來學習paxos的算法的流程(2階段提交)，有2個Client(老闆，老闆之間是競爭關係)和3個Acceptor(政府官員)：如今須要對一項議題來進行paxos過程，議題是「A項目我要中標！」，這裏的「我」指每一個帶着他的祕書Proposer的Client老闆。Proposer固然聽老闆的話了，趕忙帶着議題和現金去找Acceptor政府官員。做爲政府官員，固然想誰給的錢多就把項目給誰。Proposer-1小姐帶着現金同時找 到了Acceptor-1~Acceptor-3官員，1與2號官員分別收取了10比特幣，找到第3號官員時，沒想到遭到了3號官員的鄙視，3號官員告訴 她，Proposer-2給了11比特幣。不過不要緊，Proposer-1已經獲得了1,2兩個官員的承認，造成了多數派(若是沒有造成多數 派，Proposer-1會去銀行提款在來找官員們給每人20比特幣，這個過程一直重複每次+10比特幣，直到多數派的造成)，滿意的找老闆覆命去了，但 是此時Proposer-2保鏢找到了1,2號官員，分別給了他們11比特幣，1,2號官員的態度馬上轉變，都說Proposer-2的老闆懂事，這下子 Proposer-2放心了，搞定了3個官員，找老闆覆命去了，固然這個過程是第一階段提交，只是官員們初步接受賄賂而已。故事中的比特幣是編號，議題是 value。　　　　這個過程保證了在某一時刻，某一個proposer的議題會造成一個多數派進行初步支持； ===============華麗的，第一階段結束================　　5.　如今進入第二階段提交，如今proposer-1小姐使用分身術(多線 程併發)分了3個本身分別去找3位官員，最早找到了1號官員籤合同，遭到了1號官員的鄙視，1號官員告訴他proposer-2先生給了他11比特幣，因 爲上一條規則的性質proposer-1小姐知道proposer-2第一階段在她以後又造成了多數派(至少有2位官員的贓款被更新了);此時她趕忙去提 款準備從新賄賂這3個官員(從新進入第一階段)，每人20比特幣。剛給1號官員20比特幣， 1號官員很高興初步接受了議題，還沒來得及見到2,3號官員的時候這時proposer-2先生也使用分身術分別找3位官員(注意這裏是 proposer-2的第二階段)，被第1號官員拒絕了告訴他收到了20比特幣，第2,3號官員順利簽了合同，這時2，3號官員記錄client-2老闆 用了11比特幣中標，由於造成了多數派，因此最終接受了Client2老闆中標這個議題，對於proposer-2先生已經出色的完成了工做；這時proposer-1小姐找到了2號官員，官員告訴她合同已經簽了，將合同給 她看，proposer-1小姐是一個沒有什麼職業操守的聰明人，以爲跟Client1老闆混沒什麼前途，因此將本身的議題修改成「Client2老闆中 標」，而且給了2號官員20比特幣，這樣造成了一個多數派。順利的再次進入第二階段。因爲此時沒有人競爭了，順利的找3位官員籤合同，3位官員看到議題與 上次一次的合同是一致的，因此最終接受了，造成了多數派，proposer-1小姐跳槽到Client2老闆的公司去了。===============華麗的，第二階段結束===============　　Paxos過程結束了，這樣，一致性獲得了保證，算法運行到最後全部的 proposer都投「client2中標」全部的acceptor都接受這個議題，也就是說在最初的第二階段，議題是先入爲主的，誰先佔了先機，後面的 proposer在第一階段就會學習到這個議題而修改本身自己的議題，由於這樣沒職業操守，才能讓一致性獲得保證，這就是paxos算法的一個過程。原來 paxos算法裏的角色都是這樣的不靠譜，不過不要緊，結果靠譜就能夠了。該算法就是爲了追求結果的一致性。