[轉]圖解分布式一致性協議Paxos

標籤：

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

<分布式系統的交易處理>：

Google Chubby的作者MikeBurrows說過這個世界上只有一種一致性演算法，那就是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 preparerequest with number n to a majority of acceptors.

(b) If an acceptor receives a prepare request with number n greaterthan that of any prepare request to which it has already responded,then it responds to the request with a promise not to accept anymore proposals numbered less than n and with the highest-numberedpro-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 acceptrequest to each of those acceptors for a proposal numbered n with avalue v , where v is the value of the highest-numbered proposalamong the responses, or is any value if the responses reported noproposals.

(b) If an acceptor receives an accept request for a proposalnumbered n, it accepts the proposal unless it has already respondedto 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後面。proposenumber簡稱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 aprepare request having a number greater than n.

總結

LeslieLamport沒有用數學描述Paxos，但是他用英文闡述得很清晰。將Paxos的兩個Phase的內容理解清楚，整個演算法過程還是不複雜的。

至於Paxos中一直提到的一個全域唯一且遞增的proposer number，其如何?，引用如下：

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

 

本文部分轉自部落格：http://blog.sina.com.cn/s/blog_65309a0f0102vnw5.html

[轉]圖解分布式一致性協議Paxos