Paxos算法 -- 學習

     Paxos算法解決的問題是保證分佈式系統每次執行的操做強一致性。在其餘文檔也提到這個算法適合高帶寬低延遲網絡，若是是低帶寬網絡能夠選擇PNUTS模式 。每次執行Paxos算法都是相對獨立的，Paxos算法在整個系統運行中迭代前進。 （建議先看了wiki對Paxos解釋以後再看本文）

一、做用

     

     

     要使用Paxos算法必須保證所在的 網絡可靠，所謂可靠，只數據傳輸包不會被更改，可是能夠丟失。並且容許最多n臺Server暫停或者宕機（總Server臺數爲2n+1），宕機或者休眠的Server要參與Paxos算法（或說選舉），必須先學習以前已經經過Paxos算法的操做。（chosen value）

二、實現解析及流程

    

      沿用wiki中文，首先將角色分紅三種 proposers，acceptors，和 learners。 Leslie Lamport給出了paxos算法的精肯定義：

•      決議（value）只有在被 proposers 提出後才能批准（未經批准的決議稱爲「提案（proposal）」）；
•      在一次 Paxos 算法的執行實例中，只批准一個 Value；
•      learners 只能得到被批准（chosen）的 Value。

      其實，最難懂的仍是第二個（感受 Leslie  Lamport解釋得也有點太難理解 ），在wiki中文提到的P一、P二、P2a等其實都是爲了保證約束2能過實現。paxos核心實現就是經過大多數（超過一半）的acceptor投票經過決議（value），一旦經過決議，就表明這次決議（這一輪的paxos算法） 結束。以後value會記錄到每一個server中，以及被learner角色所學習。宕機的服務器，可經過學習以前經過決議的value恢復到與其餘server一致的狀態。

     整個的流程就是：

     客戶端C1發起請求 -->  

          S1服務端發起一輪paxos算法 -->  

               生成編號(整個分佈式系統中惟一的標識)廣播給S二、S三、...  (Perpare(N)) - -> 

     其餘服務器檢查本身是否有大於N的編號，若是有，則告知S1，S1則從新生成比該編號大的新編號再Prepare(M)，M > N，不然返回Promise，   Promise包含最近經過決議的value值和該value對應的編號(能夠爲null，Promise是其餘服務器對S1的承諾，承諾不會表決比N編號還小的決議，而且保存N爲服務器接收到的最大編號)  - ->  

     S1接到Promise以後（超過半數Server），發起表決accept（N，value), 若是 Promise裏面的value爲空，則S1可使用任意的值寫入accept，不然只能從超過半數的Server中取Promise編號最大的value做爲值  --> 

     accept() 到其餘服務器以後，其餘服務器會比較所接收到的accept所含有的編號是否小於當前保存的最大編號，若是是的話，則決絕accept，不然accepted(N, value)經過，將回復給S1 --> 

至此S1就會廣播最終的決議，結束  -->

     learner學習決議 

    

     這樣一次 paxos 算法完成，其餘客戶端再請求時，已是另外一輪paxos了。一輪paxos中，可能多個客戶端會發起請求，在這個請求競爭中會決勝出一個請求執行，沒有拿到執行的請求能夠經過遞增編號，最終有機會獲得執行。

     

三、約束

      Lamport所提到的一些約束都是爲了保證每次角逐中能生成一個惟一的value，並且該value的編號在此次paxos中是最大的。若是某次proposer給acceptor的prepare被reject，那麼proposer會遞增編號n+i （n爲服務器的個數）。

P1：一個 acceptor 必須批准它接收到的第一個 value。

     在這裏，有個歧義，並非真的批准value，其實若是，批准了第一個value，那第二個 proposal呢？根據 Paxos算法1-算法造成理論 這篇文章，實際上是promise，而不是accept。

P2：一旦一個 value 被批准(chosen)，那麼以後批准(chosen)的 value 必須和這個 value 同樣。

     由於一次角逐中，可能存在多個大於半數的集合（Ua、Ub...）在決議，由於都大於半數，Ua 與 Ub 交集不爲空，一旦其中一個集合的決議批准，那麼另外一個也要跟着表決爲該value。

     

P2a：一旦一個 value v 被批准(chosen)，那麼以後任何 acceptor 再經過(accept)的 value 必須是 v。

P2b：一旦一個 value v 被批准(chosen)，那麼之後 proposer 提出的新提案必須具備 value v。

P2c：若是一個編號爲 n 的提案具備 value v，那麼存在一個多數派，要麼他們中沒有人經過(accept)過編號小於 n 
的任何提案，要麼他們進行的最近一次批准(chosen)具備 value v。

     P2a、P2b、P2c都是爲了保證P2, 其實 聯想整個流程，P2c -> P2b -> P2a -> P2 是有理可尋的，若是proposer提案的動做被限制只能是value v，那麼P2a裏面acceptor也就只能收到value v了。

     請記住Paxos是迭代進行的，value決議以後，就是該次Paxos算法結束。

     這樣C一、C二、C3前後提出R1（請求）、R二、R3，在每一次Paxos算法的角逐之中，會按必定的順序保存到每一個服務器中。可是不必定按着一、二、3來，網絡傳輸的延遲或者丟失是很正常的。

     對Paxos算法的進一步瞭解可參照：  http://www.doc88.com/p-052298384596.html