Paxos算法簡介

應用場景

Paxos算法用於解決在分佈式環境中，如何就某個協議達成一致的問題。

背景——拜占庭將軍問題

拜占庭將軍問題是由Paxos算法做者萊斯利·蘭伯特提出的一個點對點通訊時的基本問題：在不可靠信道上試圖經過消息傳遞方式達到一致性是不可能的。這裏簡單畫個草圖：

拜占庭帝國有一支龐大的軍隊，這隻軍隊有多個小分隊（A-B-C-D-E），分別位於帝國的各個角落。一天，E分隊的將軍打算對某個倒黴國家發動進攻，可是必需要獲得全部小分隊的贊成才能執行。無奈這座帝國太大，各個小分隊之間的信息不得不依靠信使來傳遞。因而，E分隊的將軍分別派出a、b、c、d四個信使傳遞進攻任務的信息給其餘各個分隊。此時問題來了，無法保證信息準確可靠的傳遞給他們！假如d信使本就是個叛徒，亦或是a信使在路上被人劫持，再或是b信使走到一半無路可走，等等狀況。這個其實很是相似於分佈式系統中各節點間通訊，尤爲是網絡問題，很容易致使通訊在某兩個節點間中斷。該問題有沒有解決辦法呢？有！但不是今天的重點。那麼，Paxos算法跟拜占庭將軍問題之間是什麼關係呢？答案就是：Paxos算法的前提，不存在拜占庭將軍問題。
現實中是否存在某個環境，不存在拜占庭將軍問題呢？固然有，不然Paxos算法就沒有用武之地了。咱們知道zookeeper解決一致性問題，就是對Paxos算法進行了實現，而相似於zookeeper這類分佈式系統，自己就被部署在了一個安全的局域網環境中，尤爲是生產環境，出現該問題的機率很是小，能夠簡單的認爲不存在就好了。

Paxos算法中的角色

• 提案者Proposer

提出一個方案proposal，類比剛纔提到的E將軍；

• 表決者Acceptor

對別人提出的方案進行表決，類比剛纔從A到E的將軍（E將軍本身也參與表決）；

• 同步者Learner

表決經過（少數服從多數），則進入同步階段，全部人都是同步者。同步表決經過的提案，即使是沒有經過的那些表決者們。

Paxos算法基本流程

• 每一個提案者在提出提案時都會首先獲取到一個具備全局惟一性的、遞增的提案編號 N， 即在整個集羣中是惟一的編號 N，而後將該編號賦予其要提出的提案。
• 每一個表決者在 accept 某提案後，會將該提案的編號 N 記錄在本地，這樣每一個表決者中保存的已經被 accept 的提案中會存在一個編號最大的提案，其編號假設爲 maxN。每一個表決者僅會 accept 編號大於本身本地 maxN 的提案。
• 在衆多提案中最終只能有一個提案被選定。
• 一旦一個提案被選定，則其它服務器會主動同步(Learn)該提案到本地。
• 沒有提案被提出則不會有提案被選定。

下面照樣上圖：

首先看黑色部分，E向ABCD發出一個提案，該提案的編號N=1，此前BCD三者不曾accept過別的提案，所以，各自保留的最大提案編號maxN=null，因此無條件接納，以後各自修改maxN=N=1（藍色部分）；可是A此前已經accept過編號爲2的提案（這裏能夠認爲是E在發出1號提案後，緊接着有別人發出2號提案，可是因爲網絡緣由，1號提案沒有及時發送到A，反而被2號提案搶先一步），因此A對比後來的1號提案，發現編號比本身記錄的maxN=2要小，因此不予理會。這樣，該提案就被BCD三者accept，根據少數服從多數原則，該提案被正式經過。以後進入同步階段，ABCD四者都會同步1號提案的具體內容到本地。

Paxos算法具體流程

大致上分爲兩步：prepare階段和accept階段，每一個階段都是剛剛說的基本流程的實例。

prepare階段

prepare階段能夠描述爲提案者試探性的向表決者發出提案。假設有三個提案者P1（初始N=2）、P2（初始N=1）、P3（初始N=3），相對應的，有三個表決者A1（初始maxN=0）、A2（初始maxN=0）、A3（初始maxN=0）。其實跟提案者是相同的三我的，爲了表述方便，將他們分開顯示。
①如今P1提出一個提案（A3因爲網絡延遲暫未收到該提案）以下圖所示：

A1和A2的maxN原先爲0，如今統一改成2.
②P2提出編號爲1的提案（被A2和A3收到）：

因爲A2的maxN=2，因此不予理會，A3的maxN變成1.
③P3提出編號爲3的提案（被A2和A3收到）：

A2和A3的maxN都變爲3.
④只有P2的提案沒有收到過半數的迴應，這時他有兩條路可走：放棄提案或增長N值繼續提案。這裏假設P2採用後者方案，系統爲P2提案的編號賦值爲4，繼續提案：

此時A2和A3的maxN都變成4.

accept階段

①P1提案者正式向表決者A1和A2發出提案，這時要求提案者的編號N大於等於表決者的maxN便可（不要求嚴格大於）。可是此時A2的maxN已經變爲4，因此不予理會：

②P2向A2和A3發出提案，二者都經過：

③P3向A2和A3發出提案，兩個表決者maxN=4>3，因此都不予理會。

最終，只有P2得到了超過半數的響應，也就標誌着N=4號提案（原N=1號提案）正式經過。

活鎖問題

死鎖的概念你們都清楚，可是活鎖是什麼呢？處於死鎖中的多個線程因爲資源被對方佔用，致使這些線程處於一種僵持狀態（靜止的）；而活鎖則是多個實體在兩階段提交過程當中，因爲時差和資源搶佔，致使這些實體狀態一直在發生變化，根本停不下來的一種狀態（活動的）。
在本例中，假設有兩個提案者P1和P2，他們的初始maxN值都是0：

此時P1進入proposal階段，它以N=1向本身和P2發送提案編號，二者都會接受，並修改maxN=1：

緊接着P2進入proposal階段，它以N=2向本身和P1發送提案編號，二者也都會接受，並修改maxN=2：

以後P1進入accept階段，它向自身和P2正式發送N=1的提案，很顯然，此時maxN都爲2，因此就都不接受：

P1升級本身的N值爲3，再次進入proposal階段，又成功被本身和P2接受：

如今P2進入accept階段，此時P2的N=2，天然無法經過：

因此P2升級自身的N=4，再次進入proposal階段，又被二者都接受了：

……

你們看到這兩個提案者彷佛都在跟彼此較勁兒，誰也不肯放棄——這即是活鎖的表現形式。Fast Paxos算法即是用來解決活鎖問題的一個方法，它只容許有一個提案者，好比zookeeper中，只有Leader有提案權同樣，活鎖問題不復存在。