Paxos 演算法原理與推導

LBD發表於2017-02-27

原文：www.linbingdong.com

Paxos演算法在分散式領域具有非常重要的地位。但是Paxos演算法有兩個比較明顯的缺點：1.難以理解 2.工程實現更難。

網上有很多講解Paxos演算法的文章，但是質量參差不齊。看了很多關於Paxos的資料後發現，學習Paxos最好的資料是論文《Paxos Made Simple》，其次是中、英文版維基百科對Paxos的介紹。本文試圖帶大家一步步揭開Paxos神祕的面紗。

Paxos是什麼

Paxos演算法是基於訊息傳遞且具有高度容錯特性的一致性演算法，是目前公認的解決分散式一致性問題最有效的演算法之一。

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

雖然Mike Burrows說得有點誇張，但是至少說明了Paxos演算法的地位。然而，Paxos演算法也因為晦澀難懂而臭名昭著。本文的目的就是帶領大家深入淺出理解Paxos演算法，不僅理解它的執行流程，還要理解演算法的推導過程，作者是怎麼一步步想到最終的方案的。只有理解了推導過程，才能深刻掌握該演算法的精髓。而且理解推導過程對於我們的思維也是非常有幫助的，可能會給我們帶來一些解決問題的思路，對我們有所啟發。

問題產生的背景

在常見的分散式系統中，總會發生諸如機器當機或網路異常（包括訊息的延遲、丟失、重複、亂序，還有網路分割槽）等情況。Paxos演算法需要解決的問題就是如何在一個可能發生上述異常的分散式系統中，快速且正確地在叢集內部對某個資料的值達成一致，並且保證不論發生以上任何異常，都不會破壞整個系統的一致性。

注：這裡某個資料的值並不只是狹義上的某個數，它可以是一條日誌，也可以是一條命令（command）。。。根據應用場景不同，某個資料的值有不同的含義。

問題產生的背景

問題描述

假設有一組可以提出（propose）value（value在提案Proposal裡）的程式集合。一個一致性演算法需要保證提出的這麼多value中，只有一個value被選定（chosen）。如果沒有value被提出，就不應該有value被選定。如果一個value被選定，那麼所有程式都應該能學習（learn）到這個被選定的value。對於一致性演算法，安全性（safaty）要求如下：

只有被提出的value才能被選定。
只有一個value被選定，並且
如果某個程式認為某個value被選定了，那麼這個value必須是真的被選定的那個。

我們不去精確地定義其活性（liveness）要求。我們的目標是保證最終有一個提出的value被選定。當一個value被選定後，程式最終也能學習到這個value。

Paxos的目標：保證最終有一個value會被選定，當value被選定後，程式最終也能獲取到被選定的value。

假設不同角色之間可以通過傳送訊息來進行通訊，那麼：

每個角色以任意的速度執行，可能因出錯而停止，也可能會重啟。一個value被選定後，所有的角色可能失敗然後重啟，除非那些失敗後重啟的角色能記錄某些資訊，否則等他們重啟後無法確定被選定的值。
訊息在傳遞過程中可能出現任意時長的延遲，可能會重複，也可能丟失。但是訊息不會被損壞，即訊息內容不會被篡改（拜占庭將軍問題）。

推導過程

最簡單的方案——只有一個Acceptor

假設只有一個Acceptor（可以有多個Proposer），只要Acceptor接受它收到的第一個提案，則該提案被選定，該提案裡的value就是被選定的value。這樣就保證只有一個value會被選定。

但是，如果這個唯一的Acceptor當機了，那麼整個系統就無法工作了！

因此，必須要有多個Acceptor！

只有一個Acceptor

多個Acceptor

多個Acceptor的情況如下圖。那麼，如何保證在多個Proposer和多個Acceptor的情況下選定一個value呢？

多個Acceptor

下面開始尋找解決方案。

如果我們希望即使只有一個Proposer提出了一個value，該value也最終被選定。

那麼，就得到下面的約束：

P1：一個Acceptor必須接受它收到的第一個提案。

但是，這又會引出另一個問題：如果每個Proposer分別提出不同的value，發給不同的Acceptor。根據P1，Acceptor分別接受自己收到的value，就導致不同的value被選定。出現了不一致。如下圖：

幻燈片08.png

剛剛是因為『一個提案只要被一個Acceptor接受，則該提案的value就被選定了』才導致了出現上面不一致的問題。因此，我們需要加一個規定：

規定：一個提案被選定需要被半數以上的Acceptor接受

這個規定又暗示了：『一個Acceptor必須能夠接受不止一個提案！』不然可能導致最終沒有value被選定。比如上圖的情況。v1、v2、v3都沒有被選定，因為它們都只被一個Acceptor的接受。

最開始講的『提案=value』已經不能滿足需求了，於是重新設計提案，給每個提案加上一個提案編號，表示提案被提出的順序。令『提案=提案編號+value』。

雖然允許多個提案被選定，但必須保證所有被選定的提案都具有相同的value值。否則又會出現不一致。

於是有了下面的約束：

P2：如果某個value為v的提案被選定了，那麼每個編號更高的被選定提案的value必須也是v。

一個提案只有被Acceptor接受才可能被選定，因此我們可以把P2約束改寫成對Acceptor接受的提案的約束P2a。

P2a：如果某個value為v的提案被選定了，那麼每個編號更高的被Acceptor接受的提案的value必須也是v。

只要滿足了P2a，就能滿足P2。

但是，考慮如下的情況：假設總的有5個Acceptor。Proposer2提出[M1,V1]的提案，Acceptor2~5（半數以上）均接受了該提案，於是對於Acceptor2~5和Proposer2來講，它們都認為V1被選定。Acceptor1剛剛從當機狀態恢復過來（之前Acceptor1沒有收到過任何提案），此時Proposer1向Acceptor1傳送了[M2,V2]的提案（V2≠V1且M2>M1），對於Acceptor1來講，這是它收到的第一個提案。根據P1（一個Acceptor必須接受它收到的第一個提案。）,Acceptor1必須接受該提案！同時Acceptor1認為V2被選定。這就出現了兩個問題：

Acceptor1認為V2被選定，Acceptor2~5和Proposer2認為V1被選定。出現了不一致。
V1被選定了，但是編號更高的被Acceptor1接受的提案[M2,V2]的value為V2，且V2≠V1。這就跟P2a（如果某個value為v的提案被選定了，那麼每個編號更高的被Acceptor接受的提案的value必須也是v）矛盾了。

幻燈片10.png

所以我們要對P2a約束進行強化！

P2a是對Acceptor接受的提案約束，但其實提案是Proposer提出來的，所有我們可以對Proposer提出的提案進行約束。得到P2b：

P2b：如果某個value為v的提案被選定了，那麼之後任何Proposer提出的編號更高的提案的value必須也是v。

由P2b可以推出P2a進而推出P2。

那麼，如何確保在某個value為v的提案被選定後，Proposer提出的編號更高的提案的value都是v呢？

只要滿足P2c即可：

P2c：對於任意的N和V，如果提案[N, V]被提出，那麼存在一個半數以上的Acceptor組成的集合S，滿足以下兩個條件中的任意一個：

S中每個Acceptor都沒有接受過編號小於N的提案。

S中Acceptor接受過的最大編號的提案的value為V。

Proposer生成提案

為了滿足P2b，這裡有個比較重要的思想：Proposer生成提案之前，應該先去『學習』已經被選定或者可能被選定的value，然後以該value作為自己提出的提案的value。如果沒有value被選定，Proposer才可以自己決定value的值。這樣才能達成一致。這個學習的階段是通過一個『Prepare請求』實現的。

於是我們得到了如下的提案生成演算法：

Proposer選擇一個新的提案編號N，然後向某個Acceptor集合（半數以上）傳送請求，要求該集合中的每個Acceptor做出如下響應（response）。
(a) 向Proposer承諾保證不再接受任何編號小於N的提案。
(b) 如果Acceptor已經接受過提案，那麼就向Proposer響應已經接受過的編號小於N的最大編號的提案。我們將該請求稱為編號為N的Prepare請求。
如果Proposer收到了半數以上的Acceptor的響應，那麼它就可以生成編號為N，Value為V的提案[N,V]。這裡的V是所有的響應中編號最大的提案的Value。如果所有的響應中都沒有提案，那麼此時V就可以由Proposer自己選擇。
生成提案後，Proposer將該提案傳送給半數以上的Acceptor集合，並期望這些Acceptor能接受該提案。我們稱該請求為Accept請求。（注意：此時接受Accept請求的Acceptor集合不一定是之前響應Prepare請求的Acceptor集合）

Acceptor接受提案

Acceptor可以忽略任何請求（包括Prepare請求和Accept請求）而不用擔心破壞演算法的安全性。因此，我們這裡要討論的是什麼時候Acceptor可以響應一個請求。

我們對Acceptor接受提案給出如下約束：

P1a：一個Acceptor只要尚未響應過任何編號大於N的Prepare請求，那麼他就可以接受這個編號為N的提案。

如果Acceptor收到一個編號為N的Prepare請求，在此之前它已經響應過編號大於N的Prepare請求。根據P1a，該Acceptor不可能接受編號為N的提案。因此，該Acceptor可以忽略編號為N的Prepare請求。當然，也可以回覆一個error，讓Proposer儘早知道自己的提案不會被接受。

因此，一個Acceptor只需記住：1. 已接受的編號最大的提案 2. 已響應的請求的最大編號。

小優化

Paxos演算法描述

經過上面的推導，我們總結下Paxos演算法的流程。

Paxos演算法分為兩個階段。具體如下：

階段一：(a) Proposer選擇一個提案編號N，然後向半數以上的Acceptor傳送編號為N的Prepare請求。(b) 如果一個Acceptor收到一個編號為N的Prepare請求，且N大於該Acceptor已經響應過的所有Prepare請求的編號，那麼它就會將它已經接受過的編號最大的提案（如果有的話）作為響應反饋給Proposer，同時該Acceptor承諾不再接受任何編號小於N的提案。
階段二：(a) 如果Proposer收到半數以上Acceptor對其發出的編號為N的Prepare請求的響應，那麼它就會傳送一個針對[N,V]提案的Accept請求給半數以上的Acceptor。注意：V就是收到的響應中編號最大的提案的value，如果響應中不包含任何提案，那麼V就由Proposer自己決定。(b) 如果Acceptor收到一個針對編號為N的提案的Accept請求，只要該Acceptor沒有對編號大於N的Prepare請求做出過響應，它就接受該提案。