問題

最近我們在做一個項目的時候有這樣一個需求：我們有多臺服務器資源，希望彼此協作完成一項工作。這項工作可以被劃分為N個小的模塊，但由于這項工作會依賴于持續不斷的輸入(在線業務)，因此我們無法使用人工指定的方式將此工作分發到不同服務器進行。目前我們想到一個方法，將這項工作劃分出的小模塊放到一個穩定可靠的地方，例如mola存儲系統，然后每臺服務器去存儲系統上取得一定數量的模塊進行工作，完成后再將處理的結果輸出到前述的存儲系統上。這些小的模塊雖然可以被不同的服務器運行，然后重復運行卻是不可接受的(例如我們的計費日志，重復計費是絕對不允許的)。因此，當任意一臺機器取得一些模塊并準備運行時，一定要通知到其他所有機器：這些模塊已經由我運行，確認其他所有機器不會挑選到重復的模塊。這個問題難住了我們，究竟應當如何使一個分布式系統(例如我們的服務器資源)有效快速的達成一致？[1]

?

Paxos是什么[2]

Paxos也許是分布式系統中最有名的一致性協議了。Chubby論文[3]中提到：目前已有的所有一致性協議的精髓其實只有一個，那就是paxos。而paxos本身的發表過程也被傳為經典：Lamport于1990年提出此算法，并以一個虛構的希臘城邦paxos為例對此算法進行了詳細的介紹與分析；然而算法本身過于復雜，幾個編輯建議Lamport將其論文更改為數學語言重新進行描述。大牛Lamport認為他們沒有幽默感，拒絕更改。直到1998年，paxos算法才被發表在ACM Transactions on Computer Systems。2001年，Lamport覺得同行無法接受他的幽默感，于是改用平實的方式重新發表了論文，即 Paxos made simple。后來，google的chubby系統使用了Paxos作為其一致性協議，從此 Paxos協議終于得登大雅之堂

Paxos的完整過程

Paxos本身的推導過程十分復雜，要跟上作者的思維實屬不易，對其推導及原因感興趣的讀者可以仔細研究下Paxos相關的幾篇論文，在此不作翻譯了J。我會直接告訴大家Paxos的做法，以及這種做法如何能保證一致性的證明。請注意我描述的是basic paxos，對于優化的考慮并不在此進行

Paxos將系統角色分為三類：Proposer，Acceptor，Learner[4]。其中Proposer即前文問題中取得模塊并希望運行的機器，它提出：第N個模塊希望由我取得并運行；Acceptor角色即所有的服務器，它們會對Porposer提出的方案進行裁決，以確認是否同意Porposer的請求，并視情況對Proposer進行回復，Acceptor的一次回復被稱為一次投票；Learner可以是任意希望獲取模塊處理情況的機器，它通過向Acceptor發送學習請求而獲知所有模塊的分配情況(當然，當Acceptor同意Porposer請求的時候也可以主動的通知Learner，這兩種方式的區別并不是本文的重點)。很明顯，我們的服務器實際上至少同時兼任了兩個角色：Proposer及Acceptor，在需要知道當前分配情況的時候還需要扮演Learner。

另外，Paxos還引入議案的概念，議案內容為<序列號，方案>。序列號是Porposer自行產生的單調遞增的數字，并且所有的Porposer提出的序列號不能一樣。如何使所有Porposer產生不同的序列號不在本文討論范圍；舉個簡單例子，每個Porposer都保持一個序列號集合{Porposer id+Porposer數量*N，N=1,2,3……}即可。

Paxos有一個很重要的概念，多數派。Paxos中的多數派意義為：對于參加本次投票的Acceptor集合，如果它和之前任意一次成功投票的Acceptor集合的交集都不為空，則稱本次投票的Acceptor集合達到多數派條件，并且本次投票也是一個成功的投票。這個說法過于晦澀，在不考慮權重的情況下，我們可以簡單理解為：所有Acceptor機器數量為N，則多數派指的是參與投票的Acceptor數量達到或超過? (N+1)/2?。只有滿足多數派條件的投票才是一次成功的投票

下面描述Paxos算法的詳細過程。

Proposer過程：

1.每當Porposer希望提出方案V1，首先發出prepare請求至Acceptor。Prepare請求內容為<序列號SN1>

2.經過一段時間，收到一些Acceptor回復，回復可分為以下幾種

a)???????? 回復數量滿足多數派，并且所有的回復都是<OK>，則Porposer發出accept請求，請求內容為議案<SN1，V1>

b)???????? 回復數量滿足多數派，但有的回復為：<SN2，V2>，<SN3，V3>……則Porposer找到所有回復中序列號最大的那個，假設為<SNx，Vx>發出accept請求，請求內容為議案<SN1，Vx>

c)???????? 回復數量不滿足多數派，Proposer嘗試增加序列號為SN1+，轉1繼續執行

3.經過一段時間，收到一些Acceptor回復，回復可分為以下幾種

a)???????? 回復數量滿足多數派，則確認V1被接受

b)???????? 回復數量不滿足多數派，V1未被接受，Proposer增加序列號為SN1+，轉1繼續執行

上文中步驟(3)與(2)的區別在于(3)僅判斷了回復的數量，而對回復內容未進行判斷。因為對于accept請求，如果Acceptor回復就表示接受了

Acceptor過程：

1.當Acceptor接收到prepare請求<SN1>時，檢查自身上次回復過的prepare請求<SN2>

a)???????? 如果SN2>SN1，則忽略此請求，直接結束本次批準過程

b)???????? 否則檢查上次批準的accept請求<SNx，Vx>，并且回復<SNx，Vx>；如果之前沒有進行過批準，則簡單回復<OK>

1.當Acceptor接收到Accept請求<SN1，V1>時，檢查自身上次回復過的prepare請求<SN2>(注意Acceptor可能在沒有收到prepare請求的情況下接收到accept請求，因為Porposer并不保證只將accept請求發送給那些回復它prepare請求的Acceptor；同理，Acceptor回復prepare請求后也并不保證一定能收到accept請求。此處的SN2與步驟(1)中的SN2可能不一致)[5]

a)???????? 如果SN2>SN1，則忽略此請求，直接結束本次批準過程

b)???????? 否則直接批準此Accept請求

如果我們需要學習到當前的方案，則我們可以扮演一個Learner的角色。Learner向所有的Acceptor發出學習請求，Acceptor收到此請求時回復自身上次批準的<SNx，Vx>，當Learner學習到一個經多數派Acceptor批準的<SNx，Vx>時，則說明Vx得到最終的通過，此時稱為Vx這個方案被選擇了

Paxos協議里面有幾點需要特別注意，也請大家思考：

1.一個Acceptor是否可能批準不同的方案？

2.Acceptor本身是否知道一個方案被選擇了？

3.在Proposer的階段(2c)中，如果此時有其他的Porposer在提交方案引起沖突，是否會引起震蕩的提交？

4.一個方案已經被選擇了，之后是否可以重復提出此方案進行提交？

5.Acceptor是否可能重復批準相同的方案？

6.是否可能出現一個方案被選擇后，Learner學習不到的情況？即，一個方案被選擇了，但Proposer，Acceptor，Learner都不清楚是否有方案被選擇，哪個方案被選擇？如果會，那么Paxos協議如何保證進展及一致性？

不嚴謹的證明

對上述過程進行歸納總結，采用文字描述的Paxos協議整個過程如下：[6]

將一個議案的選擇過程分為兩個階段：

prepare 階段：

Porposer 選擇一個序列號SN 并將 prepare 請求發送給 Acceptors 中的一個多數派；

Acceptor 收到 prepare 消息后，如果提案的編號大于它已經回復的所有 prepare 消息，則 Acceptor 將自己上次的批準回復給 Porposer，并承諾不再批準序列號小于SN的提案，同時不再響應序列號小于SN的prepare消息；

批準階段：

當一個 Proposer 收到了多數 Acceptors 對 prepare 的回復后，就進入批準階段。它要向一個多數派 Acceptor 發送 accept 請求，包括編號 SN 和根據前述條件確定的value。

在不違背自己向其他 Porposer 的承諾的前提下，Acceptor 收到 accept 請求后即批準這個請求。

這個過程在任何時候中斷都可以保證正確性(即在任何情況下算法都可以保證一致性)。在其過程中并不保證任意一次請求一定能得到響應，在任一步驟中發生Proposer或Acceptor失效都不會影響算法的正確性。

對于算法的正確性，Paxos論文中本身已有嚴謹證明，雖然嚴謹卻難于理解。我嘗試給出不那么嚴謹的證明方式如下：

兩個條件：

1.多數派批準，被稱為value被選擇

2.Prepare消息回復中，要么：所有的回復中沒有批準value，要么本次提交所有回復中最大SN號的那個value

Paxos認為滿足上述條件就能保證一致性。那么：

1.如果所有prepare回復中沒有批準value，那么隨意提交一個value不會造成不一致，這是顯然的，因為多數派Acceptor并沒有批準任意一個議案

2.假設在第K次有方案v被選擇(即多數派Acceptor對議案<K，v>進行了批準，此時Learner已經可以學習到方案v)，如果上述算法不能滿足一致性，則必然存在第K+m次有方案v1被選擇，且v1!=v，且第K+1，K+2,……K+m-1次中都沒有任何方案被選擇。根據上述條件(2)，第K+1，K+2，……K+m-1次所提出的方案都是v1，則：第K+m次的prepare請求中，沒有收到<Kx，v>這樣的回復。存在一個多數派，其在第K，K+1，K+2，……K+m-1次中均沒有進行過方案v的批準，而這與方案v在第K次被通過沖突，因此，假設不成立，上述算法一定能滿足一致性要求，Paxos算法的正確性得到證明

問題解決

我們將上述達成一致的過程稱為一次Paxos運行實例。顯然，單實例的Paxos沒有任何意義，我們并不需要一個只能達成一個值并且從此不變的協議。為此，我們擴充到multi-paxos。在prepare請求和accept請求中都加入實例號N，所謂一致性僅在一個實例內部有意義。以鎖操作為例，我們希望：首先加鎖，然后解鎖，這就是兩個paxos實例，這兩個實例的實例號可以使用鎖的序列號來表示。則對于任一客戶端，加鎖解鎖的過程變為：Learner首先取得當前已完成的鎖序列號Lx，如果當前最新序列號中鎖的狀態是解鎖，則提出議案<Lx，SNx，加鎖服務器id>，如果加鎖失敗(即本地Learner未收到多數派加鎖成功消息，或者加鎖成功消息中的方案與本機提出的不一致)，則從頭開始重新進行

最終，我們成功使用Paxos解決了前面提出的問題。任務分解出來的模塊進行順序編號，每個模塊都有自身的惟一編號，以這個號做為Paxos的實例號。服務器每當獲取一個模塊N(此時作為Proposer)時，會發出議案<N，SN，服務器id>，然后服務器開始等待學習議案<N>；當學習到<N，SN，服務器M>時，認為模塊N已經被服務器M所運行，之后的判斷，比如M是否是自身，不是的話后續如何處理等，交由用戶邏輯處理[7]

參考文檔

[1] The Part-Time Parliament，Lamport，1998，ACM Transactions on Computer Systems

[2] Paxos Made Simple，Lamport，2001年

[3] http://libpaxos.sourceforge.net/ ，paxos的開源實現

[4] http://zh.wikipedia.org/zh-cn/Paxos算法 ，wikipedia上的中文說明

[5] http://en.wikipedia.org/wiki/Paxos_algorithm ，wikipedia上的英文說明

[6] http://labs.google.com/papers/chubby-osdi06.pdf ，chubby論文，關于paxos的使用

---

[1]為避免讀者誤會，我虛構了上述場景及其解決方案。我所描述的解決方案顯然不是最優的，但這不是重點，重點是paxos確實可以解決我們碰到的這個問題?
[2] 之所以要寫Paxos，是因為網上流傳的一些關于Paxos的描述不盡準確，并且大家抄來抄去，當你讀到1千篇文章的描述都一樣時，很可能會把錯的也當成對的。另外，st的此次活動是促使動筆的直接因素，在此表示感謝
[3] 可以認為chubby論文的發表將對Paxos的研究推向熱潮，chubby文章可以參考附件
[4] 對于這三者的概念，可以參考《Paxos made simple》，比起原始的論文《The Part-Time Parliament》要簡單許多
[5] 對于accept請求的發送，wiki中文及《Paxos made simple》中提到，需要發送給回復prepare請求的多數派Acceptor，但《The Part-Time Parliment》中沒有此要求，可以隨意發送給一個多數派集群即可。另外參考了開源的libpaxos做法，其所有的請求都是采用直接廣播的方式進行。此處采用發送給任一多數派的說法，因為我認為這樣做并不會引起不一致，并且在實現上更加簡單，只需要按照libpaxos，每次都將accept請求往Acceptor集群進行廣播即可

?

[6] 此處的描述引用了wiki中文關于Paxos的相關條目，但有所更改，因為我認為wiki中文中對于Paxos的描述主要參考的是Paxos made simple，并且做了一些優化，而對于basic paxos的描述有些地方并不準確。詳情見http://zh.wikipedia.org/zh-cn/Paxos算法

[7] 同前述，本例子只是虛構的，用來引出Paxos算法。請不要太認真的對待這個例子的解決方式

作者:helei

?

【本文首發于：搜索研發部官方博客】http://stblog.baidu-tech.com/?p=1196 【關注百度技術沙龍】

轉載于:https://blog.51cto.com/baidutech/742999

總結

以上是生活随笔為你收集整理的Paxos小议的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。