【分佈式協調】之理解paxos

感嘆一下

　　不得不說近幾年國內軟件行業發生了巨大的變化，以前幾乎全部應用都圍繞桌面展開，而近幾年不少讓人神魂顛倒的關鍵詞一個接一個的映入眼簾：web2.0、移動應用、雲計算、大數據。互聯網的浪潮一波接着一波，咱們這代人也鑑證了在一次次的革命中科技企業的興衰成敗。貌似說的有些遠了，其實我只是想說，互聯網的繁榮會產出大規模的數據，一定給分佈式技術帶來的無比巨大的挑戰，因此咱們應該理解其基本原理來更好的投身於咱們的事業之中~

　　進入正題。我是根據wiki上的算法描述來解釋的，第一次看wiki的描述感受摸不着頭腦，有些地方總以爲不對，可是後來細細品味，wiki的文字並無疏忽。

　　另外本人利用閒暇時間開發出了一個類Paxos的工程實現，借鑑了chubby以及zookeeper等項目的一些工程化方法，代碼已經開源：https://github.com/15Koala/cocklebur 目前已經實現自動選主，數據服務還在開發階段。後續我會把實現的具體細節以博客的形式發表出來，但願能和你們多多交流！

用Paxos作什麼？

　　Paxos是一種使多個個體達成一致的一種協議，他被普遍的應用在分佈式領域當中。然而你們在真正用它的時候都會選擇類paxos去實現，而paxos則被認爲是各類版本的類paxos的源頭。Paxos致力解決在消息重複、丟失、延遲的狀況下分佈式系統消息傳遞一致性的保證，若是每一個節點都遵照該協議那麼就能夠一致。

　　可能說道這裏，有些人會感到困惑，什麼叫達成一致呢？這跟整個集羣有什麼關係？好，那我說個具體的例子，好比：你想讓一個集羣啓動後自動的選舉出一個主節點做爲master，你可能會說，我配置好了就OK了，可是master掛了怎麼辦？Paxos可讓集羣自動選舉出master，「選舉」要比「任命」更魯棒。而選舉的過程其實就是修改節點狀態（節點上的數據）的過程，你們根據統一的約定（Paxos協議）去選出一個master。

Paxos協議的描述

　　如今咱們過一遍Paxos算法的內容，此時必定不要想太多工程實現上的細節問題，如今咱們只需瞭解它怎麼去工做就行了，由於具體實現與下面陳述的截然不同。

　　首先，過程涉及三種角色，提案者（proposer），評議者（acceptor），使用提案的人（learner）。通俗點說就是proposer們要給acceptor們提一些提案，讓acceptor最終敲定一個提案，敲定以後再通告全部的learner們。補充一句，爲了打消你的一些疑慮，補充下面幾點：1. proposer能夠提交不少次本身的提案（由於這至關於消息重發）；2. 也能夠沒讓某些acceptor收到本身的提案（由於這至關於丟包了，但不能所有都收不到啊，這樣這個提案就徹底沒意義了），3. Acceptor收到的提案能夠順序錯亂的（這至關某些消息延遲了）；4. 每一個proposer都沒有說違心的話，都有啥說啥了（這至關於沒有拜占庭問題，發送的信息都是正確無誤的）。

　　OK，到了如今人物出場完畢，接下來解釋一下提案過程所涉及的概念：

　　

提案（value）:每一個proposer向acceptor們提交提案時都會附帶一個序號（自增的，你能夠把提交的時間戳做爲它的序號），之因此須要這個編號，是讓它做爲acceptor取捨提案的依據。可是value是提案的惟一標識，好比，一個proposer提了兩次value = v1的提案，雖然第二次的序號要比第一次大，可是依然是同一個提案。

多數派（majority）：多數派是全部acceptor的一個子集，元素個數多餘一半就稱之爲多數派。他表明了某一羣acceptor。根據抽屜原理，任意兩個多數派之間必然有交集。

接受（accept）：acceptor總會接收它收到的第一個提案；若是序號比以前接受的提案序號都高，那麼它也會接收提案；

批准（chosen）:一個多數派接受了一個提案，而且在該proposer發送accept請求確認以後，那麼咱們說該提案被批准。

prepare請求：提案請求，proposer 向acceptor多數派發送提案請求。

accept請求：批准請求，proposer 徵求acceptor批准本身的提案。

　　

OK，咱們來看一下Paxos提案兩個階段：

A.準備（prepare）階段：

 

1.proposer 選擇一個提案編號 n （在proposer 角度看永遠是自增的，可是在acceptor角度看就不必定了，由於可能延遲，你懂的）並將提案（value）發送給 acceptors 中的一個多數派（就是說超過一半的acceptor接收到了，但不能說是proposer 發送給了多一半的人，由於這並不能保證多數派收到提案，時時刻刻要提醒本身，發送不必定能收到！要仔細體會前面幾句的區別哦）；

2.acceptor 收到提案後，若是提案的編號大於它已經回覆的全部提案的編號，接收該提案（約束P1a，見wiki百科）。acceptor 將本身上次接受的提案回覆給 proposer（其實這裏主要是爲了優化用的，由於proposer若是知道了有跟本身不同且編號較大的提案，他本身就不會再去申請了），而後，並承諾給該proposer再也不回覆小於 n 的提案；

 

B.批准（chosen）階段：

1.當一個 proposor 收到了多數 acceptors 對 prepare 的回覆後，就進入批准（chosen）階段。他要向回覆提案請求的 acceptors 發送 accept 請求，包括編號 n 和他的value（注意，此時可能會有多個proposor 認爲本身已經被多數派承認，由於acceptors 在接受proposor1以後可能有來了一個持有更大編號的proposor2，實際上此時多數派可能更支持proposor2。另外須要再次強調一下，多數派一旦持有一個意見以後，不可能在找出持有其餘意見的多數派，由於任意兩個多數派必有交集，因此能夠反證之）；
2.在不違背本身向其餘 proposer 的承諾的前提下（上文提到過這個承諾-再也不接收編號更小的提案，言外之意，若是在該proposor發送accept請求以前，多數派成員發現了序號更高並且跟該proposor的提案不一樣的提案，那麼確定就接受了），acceptor 收到 accept 請求後即接受這個請求（若是acceptors們發現此時發accept請求的proposor持有的value並非當前acceptor所接受的，那麼將不會接受，因此接受的數量構不成多數派，那麼該提案就失敗了，若是構成多數派，那麼就批准了）。

　　

　　到此，整個協議就描述完畢，你可能更加關心各類異常情形。由於單從上面的描述中很難看出遇到異常狀況如何去決策。

　　好比，一個常見的問題就是若是在批准階段，一個proposor沒有被批准（雖然他以前還看到但願來着），他發送的accept請求已經被某些acceptor所接受了，那麼這些acceptor就不會在接受其餘的value了，那他們之後怎麼辦？我想持有這樣問題的朋友必定是在想這並非全部人達成一致呀！沒錯，在批准的那一刻並非全部人都一致，而是一個多數派一致了，那麼這就夠了，由於只要找出一個多數派批准，那麼咱們就強行決定，全部人都應該批准！

　　再好比一個問題：批准以後要是一個持有更高編號的延遲了，致使讓編號較小的人率先得到多數派的批准。回答是隻能對那些晚了的人表示遺憾了，由於有些事一旦錯過就不在...這裏不是開玩笑，是由於有些超時的行爲是須要去權衡的，你也可能設定一個等待時間，在批准前先等一等，看看有沒有晚來的「優秀提案」。

　　參考文獻：http://zh.wikipedia.org/wiki/Paxos%E7%AE%97%E6%B3%95