圖解分佈式一致性協議Paxos

Paxos協議/算法是分佈式系統中比較重要的協議，它有多重要呢？

<分佈式系統的事務處理>：

Google Chubby的做者Mike Burrows說過這個世界上只有一種一致性算法，那就是Paxos，其它的算法都是殘次品。

<大規模分佈式存儲系統>：

理解了這兩個分佈式協議以後(Paxos/2PC)，學習其餘分佈式協議會變得至關容易。

學習Paxos算法有兩部分：a) 算法的原理/證實；b) 算法的理解/運做。

理解這個算法的運做過程其實基本就能夠用於工程實踐。並且理解這個過程相對來講也容易得多。

網上我以爲講Paxos講的好的屬於這篇：paxos圖解及Paxos算法詳解，我這裏就結合wiki上的實例進一步闡述。一些paxos基礎經過這裏提到的兩篇文章，以及wiki上的內容基本能夠理解。

算法內容

Paxos在原做者的《Paxos Made Simple》中內容是比較精簡的：

Phase 1

(a) A proposer selects a proposal number n and sends a prepare request with number n to a majority of acceptors.

(b) If an acceptor receives a prepare request with number n greater than that of any prepare request to which it has already responded, then it responds to the request with a promise not to accept any more proposals numbered less than n and with the highest-numbered pro-posal (if any) that it has accepted.

Phase 2

(a) If the proposer receives a response to its prepare requests (numbered n) from a majority of acceptors, then it sends an accept request to each of those acceptors for a proposal numbered n with a value v , where v is the value of the highest-numbered proposal among the responses, or is any value if the responses reported no proposals.

(b) If an acceptor receives an accept request for a proposal numbered n, it accepts the proposal unless it has already responded to a prepare request having a number greater than n.

借用paxos圖解文中的流程圖可歸納爲：

實例及詳解

Paxos中有三類角色Proposer、Acceptor及Learner，主要交互過程在Proposer和Acceptor之間。

Proposer與Acceptor之間的交互主要有4類消息通訊，以下圖：

這4類消息對應於paxos算法的兩個階段4個過程：

• phase 1
  • a) proposer向網絡內超過半數的acceptor發送prepare消息
  • b) acceptor正常狀況下回復promise消息
• phase 2
  • a) 在有足夠多acceptor回覆promise消息時，proposer發送accept消息
  • b) 正常狀況下acceptor回覆accepted消息

由於在整個過程當中可能有其餘proposer針對同一件事情發出以上請求，因此在每一個過程當中都會有些特殊狀況處理，這也是爲了達成一致性所作的事情。若是在整個過程當中沒有其餘proposer來競爭，那麼這個操做的結果就是肯定無異議的。可是若是有其餘proposer的話，狀況就不同了。

以paxos中文wiki上的例子爲例。簡單來講該例子以若干個議員提議稅收，肯定最終經過的法案稅收比例。

如下圖中基本只畫出proposer與一個acceptor的交互。時間標誌T2老是在T1後面。propose number簡稱N。

狀況之一以下圖：

A3在T1發出accepted給A1，而後在T2收到A5的prepare，在T3的時候A1才通知A5最終結果(稅率10%)。這裏會有兩種狀況：

• A5發來的N5小於A1發出去的N1，那麼A3直接拒絕(reject)A5
• A5發來的N5大於A1發出去的N1，那麼A3回覆promise，但帶上A1的(N1, 10%)

這裏能夠與paxos流程圖對應起來，更好理解。acceptor會記錄(MaxN, AcceptN, AcceptV)。

A5在收到promise後，後續的流程能夠順利進行。可是發出accept時，由於收到了(AcceptN, AcceptV)，因此會取最大的AcceptN對應的AcceptV，例子中也就是A1的10%做爲AcceptV。若是在收到promise時沒有發現有其餘已記錄的AcceptV，則其值能夠由本身決定。

針對以上A1和A5衝突的狀況，最終A1和A5都會廣播接受的值爲10%。

其實4個過程當中對於acceptor而言，在回覆promise和accepted時因爲均可能由於其餘proposer的介入而致使特殊處理。因此基本上看在這兩個時間點收到其餘proposer的請求時就能夠了解整個算法了。例如在回覆promise時則可能由於proposer發來的N不夠大而reject：

若是在發accepted消息時，對其餘更大N的proposer發出過promise，那麼也會reject該proposer發出的accept，如圖：

這個對應於Phase 2 b)：

it accepts the proposal unless it has already responded to a prepare request having a number greater than n.

總結

Leslie Lamport沒有用數學描述Paxos，可是他用英文闡述得很清晰。將Paxos的兩個Phase的內容理解清楚，整個算法過程仍是不復雜的。

至於Paxos中一直提到的一個全局惟一且遞增的proposer number，其如何實現，引用以下：

如何產生惟一的編號呢？在《Paxos made simple》中提到的是讓全部的Proposer都從不相交的數據集合中進行選擇，例如系統有5個Proposer，則可爲每個Proposer分配一個標識j(0~4)，則每個proposer每次提出決議的編號能夠爲5*i + j(i能夠用來表示提出議案的次數)

參考文檔

• paxos圖解, http://coderxy.com/archives/121
• Paxos算法詳解, http://coderxy.com/archives/136
• Paxos算法 wiki, http://zh.wikipedia.org/zh-cn/Paxos%E7%AE%97%E6%B3%95#.E5.AE.9E.E4.BE.8B