Paxos——分佈式一致性算法

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

Paxos算法問世已經有將近30年的歷史了，是目前公認最有效的解決分佈式場景下一致性問題的算法之一，可是缺點是比較難懂，工程化比較難。本文但願可以輔以圖例和通俗易懂的實例把Paxos算法講清楚。

Paxos算法的價值

---

在分佈式系統中，在異步通信的過程當中，總會發生網絡波動、機器宕機等狀況，那麼如何在這樣複雜的狀況下，快速且安全的就某一數值達成一致呢？Paxos算法主要就是解決此類問題，在布式鎖、主從複製、命名服務、分佈式協調等常見場景下，Paxos算法都有着普遍的應用。

基本概念

---

參與角色

在Paxos算法中，全部的參與者被分爲了如下幾個角色

角色	分工	參與決策
Proposer	提出提案，提案:[編號Id,提議的Value]	√
Acceptor	接收提案，批准/拒絕提案，當提案被大多數的Acceptor(Quorum)批准後即爲被選定的提案(Chosen)	√
Learner	學習(Learn)最新被選定的提案	×

• 提案：提案是由編號及Value組成，Paxos算法須要咱們保證提案的編號Id全局惟一有序（具體有不少種實現，不在本文的討論範圍內）。
• Quorum：直譯爲法定人數，在Paxos中意爲任意兩個Quorum都包含至少一個公共成員，能夠理解爲包含Acceptor集合中的大多數成員。如一共有2F+1位Acceptor，則Quorum人數爲F+1位。
• Proposer、Acceptor、Learner只是角色的分工，在具體實現中，一個進程可能擔當不止一種角色。

Paxos算法正確的必要條件

如今將算法的參與者分爲了這樣三個角色，那麼是爲了讓他們完成什麼樣的工做目標呢？

一個分佈式算法有兩個最重要的屬性：活性、安全性

• 活性意爲「預期的事情最終必定會發生」，最終一致性就是一種活性。
• 安全性意爲違背了安全性規則，則系統會發生損失。

咱們能夠從這兩個方面來考察Paxos算法的正確性

活性：

​ 保證最終有一個提案會被選定，當提案被選定後，進程最終最終也能獲取到被選定的提案。

安全性：

• 提案(value)只有在被 proposers 提出後才能被批准。
• 在一次 Paxos 算法的執行實例中，只批准(chosen)一個 value。
• learners 只能得到被批准(chosen)的 value。

那麼咱們下面來看看具體的算法流程

算法流程

---

算法描述來自於倪超《從Paxos到ZooKeeper分佈式一致性原理與實踐》

提案的提出和批准

• 階段一

  1. Proposer選擇一個提案編號N，而後向半數以上的Acceptor發送編號爲N的Prepare請求。
  2. 若是一個Acceptor收到一個編號爲N的Prepare請求，且N大於該Acceptor已經響應過的全部Prepare請求的編號，那麼它就會將它已經接受過的編號最大的提案（若是有的話）做爲響應反饋給Proposer，同時該Acceptor承諾再也不接受任何編號小於N的提案。

• 階段二

  1. 若是Proposer收到半數以上Acceptor對其發出的編號爲N的Prepare請求的響應，那麼它就會發送一個針對[N,V]提案的Accept請求給半數以上的Acceptor。注意：V就是收到的響應中編號最大的提案的value，若是響應中不包含任何提案，那麼V就由Proposer本身決定。

  2. 若是Acceptor收到一個針對編號爲N的提案的Accept請求，只要該Acceptor沒有對編號大於N的Prepare請求作出過響應，它就接受該提案。

提案的發佈

1. acceptors須要將accept消息發送給learners的一個子集，而後由這些learners去通知全部learners。
2. 可是因爲消息傳遞的不肯定性，可能會沒有任何learner得到了決議批准的消息。當learners須要瞭解決議經過狀況時，可讓一個proposer從新進行一次提案。注意一個learner可能兼任proposer。

乾巴巴的算法描述可能比較難以理解，因此從圖解分佈式一致性協議Paxos這裏借來一個很簡明的圖來輔助理解。

從上圖看到,做爲Acceptor只須要存儲批准/保證過的提案的最大編號(MaxN)，批准過的提案的最大編號(AcceptN)，批准過的提案的Value值(AcceptV)，而後經過階段一(2)和階段二(2)的兩種規則進行對提案的審批，即可以保證審批的安全性。

而Proposer須要保證在階段一(1)時提出的提案編號惟一且單調遞增，而在階段二(1)時只對獲取到了足夠多的保證（即得到了大多數Acceptor對Proposer的保證）的提案進行提交，即可以保證提案申請的安全性。

那麼爲何這樣可以知足上面所述的分佈式算法的安全性呢？這個要從Paxos算法的推導來看。完整的推導過程能夠在wikipedia上看到。

下面我來談一談個人理解，在推導過程當中有這麼幾個重要的約束：

P1：一個 acceptor 必須接受（accept）第一次收到的提案。

P1a：當且僅當acceptor沒有迴應過編號大於n的prepare請求時，acceptor接受（accept）編號爲n的提案。

P2：一旦一個具備 value v 的提案被批准（chosen），那麼以後批准（chosen）的提案必須具備 value v。

P2a：一旦一個具備 value v 的提案被批准（chosen），那麼以後任何 acceptor 再次接受（accept）的提案必須具備 value v。

P2b：一旦一個具備 value v 的提案被批准（chosen），那麼之後任何 proposer 提出的提案必須具備 value v。

P2c：若是一個編號爲 n 的提案具備 value v，那麼存在一個多數派，要麼他們中全部人都沒有接受（accept）編號小於 n 的任何提案，要麼他們已經接受（accept）的全部編號小於 n 的提案中編號最大的那個提案具備 value v。

他們之間的關係能夠用下圖來講明

當Acceptor僅可批准一個提案時，僅依靠P1，也是可以只批准出一個Value的，可是在這種狀況下，頗有可能須要屢次重複投票過程纔可以達到一致性的狀態，也就是說雖然可以保證安全性，可是犧牲了部分的活性。以下圖所示：

Proposer老是可以優先得到同機房內的Acceptor的批准，可是很難得到其餘機房的Acceptor的批准，這時ProposerA、ProposerB、ProposerC各得到一票，每一個Proposer的提案都沒有經過，此時Proposer只能生成編號更大的提案，以期許可以得到大多數的Acceptor(2個)的批准，也許將來不久，某個lucky dog最終可以得到大多數的Acceptor的批准，可是咱們已經等的花兒都謝了。

因此爲了可以快速到達一致性，又引入了P2c和P1a，在P1a中解除了Acceptor只能批准一個提案的限制，可是增長了對於批准提案的編號的限制，在P2中增長了對Proposer提出提案的Value值的限制，這兩個限制帶來的直接效果有兩個：

1. 本來Proposer只須要和Acceptor交互一次，如今變成了兩次，在Proposer正式提交提案前，Proposer要先得到大多數的Acceptor的狀態（prepare請求），以確保提出的提案時，沒有已經經過了的提案。由於是大多數的Acceptor，因此若是有已審批的提案，那麼必定可以經過這批Prepare請求獲知，若是得知已經有審批過的提案，那麼表明Proposer已獲知本次Paxos執行實例中的決議，並將本身的提案的Value值替換爲已審批過的提案的Value值，保證安全性。
2. 由於Proposer在正式提交提案前，已經通過了「嚴格」的問詢和保證，Acceptor也會對審批的編號作審覈，因此即便Acceptor可以批准多個提案，可是會保證審批經過的提案的值都具備相同的Value值。從而保證了安全性。

這樣講可能仍是比較難以理解，咱們如今就上面那個例子作一個圖示，分別看看選出提案爲A、和提案爲B的流程。

• P表明Acceptor對Proposer的Promise
• A表明Acceptor對Proposer提案的Accept
• PE表明保證失敗，即圖一中的
• AE表明審批失敗，即圖一中的
• 提案編號由時間戳和機器Id組成，如編號爲1.2，則表明在時間戳爲1時，機器Id2提出的提案。
• 字母右邊的數字表明提案編號，如P1.1表明Acceptor對於編號爲1.1提案的Promise
• 中括號[]內爲迴應內容，如P1.1[1.2:A]表明Acceptor對於編號1.1提案的Promise，並回應「我已經審批經過了編號爲1.2，值爲A」的提案。

如圖四所示，最終造成了值爲A的提案。

如圖五所示，最終造成了值爲B的提案。

這時候停下來思考一下，嚴格來講，上面描述的犧牲活性問題並無解決，只是下降了發生了的機率，在極端狀況下仍是可以發生一種相似於「活鎖」的狀態的。以下圖所示

在極端狀況下，這種循環會一直進行下去。因此爲了解決這種問題，又提出了Multi-Paxos算法，Multi-Paxos具體算法在這裏不作陳述，它是在Proposer中又搞了一個Leader的概念，在初期，全部的Proposer中競選出一個Leader，而後只有Leader可以向Acceptor提出提案，當Leader發生問題時，再競選一個Leader出來，沒有了Proposer的競爭，兩階段也變成了一階段，提升了效率，也解決了活鎖的問題。可是仔細想一想，競選Leader的過程當中也可能會發生活鎖的，我估計這也是Raft算法被提出來的真正緣由（狗頭），畢竟最後繞了一大圈，最終仍是搞出了單點的Leader出來進行管理，還不如用上面P1+重試的機制選出Leader，效率平時是差很少的，僅在選舉Leader時會比較慢而已。

總結

---

本文分析了Paxos算法的應用價值和具體實現原理，但願能讓你們在學習Paxos算法的過程當中可以少掉一點頭髮。後續可能還會更新我對Raft算法的理解。

---

歡迎關注個人博客：王老魔的代碼備忘錄