Paxos演算法是萊斯利·蘭伯特（英語：Leslie Lamport，LaTeX中的“La”）於1990年提出的一種基於訊息傳遞且具有高度容錯特性的一致性演算法

1. 問題和假設

   1. 分散式系統中的節點通訊存在兩種模型：共享記憶體（Shared memory）和訊息傳遞（Messages passing）。基於訊息傳遞通訊模型的分散式系統，不可避免的會發生以下錯誤：程序可能會慢、被殺死或者重啟，訊息可能會延遲、丟失、重複，在基礎 Paxos 場景中，先不考慮可能出現訊息篡改即拜占庭錯誤的情況。Paxos 演算法解決的問題是在一個可能發生上述異常的分散式系統中如何就某個值達成一致，保證不論發生以上任何異常，都不會破壞決議的一致性。一個典型的場景是，在一個分散式資料庫系統中，如果各節點的初始狀態一致，每個節點都執行相同的操作序列，那麼他們最後能得到一個一致的狀態。為保證每個節點執行相同的命令序列，需要在每一條指令上執行一個“一致性演算法”以保證每個節點看到的指令一致。一個通用的一致性演算法可以應用在許多場景中，是分散式計算中的重要問題。因此從20世紀80年代起對於一致性演算法的研究就沒有停止過。

   2. 為描述 Paxos 演算法，Lamport 虛擬了一個叫做 Paxos 的希臘城邦，這個島按照議會民主制的政治模式制訂法律，但是沒有人願意將自己的全部時間和精力放在這種事情上。所以無論是議員，議長或者傳遞紙條的服務員都不能承諾別人需要時一定會出現，也無法承諾批准決議或者傳遞訊息的時間。但是這裡假設沒有拜占庭將軍問題（Byzantine failure，即雖然有可能一個訊息被傳遞了兩次，但是絕對不會出現錯誤的訊息）；只要等待足夠的時間，訊息就會被傳到。另外，Paxos 島上的議員是不會反對其他議員提出的決議的。

   3. 對應於分散式系統，議員對應於各個節點，制定的法律對應於系統的狀態。各個節點需要進入一個一致的狀態，例如在獨立 

      Cache 的對稱多處理器系統中，各個處理器讀記憶體的某個位元組時，必須讀到同樣的一個值，否則系統就違背了一致性的要求。一致性要求對應於法律條文只能有一個版本。議員和服務員的不確定性對應於節點和訊息傳遞通道的不可靠性。

2. 演算法

   1. 演算法的提出與證明

      首先將議員的角色分為 proposers，acceptors，和 learners（允許身兼數職）。proposers 提出提案，提案資訊包括提案編號和提議的 value；acceptor 收到提案後可以接受（accept）提案，若提案獲得多數 acceptors 的接受，則稱該提案被批准（chosen）；learners 只能“學習”被批准的提案。劃分角色後，就可以更精確的定義問題：決議（value）只有在被 proposers 提出後才能被批准（未經批准的決議稱為“提案（proposal）”）；在一次 Paxos 演算法的執行例項中，只批准（chosen）一個 value；learners 只能獲得被批准（chosen）的 value。另外還需要保證 progress。這一點以後再討論。

                 作者通過不斷加強上述3個約束（主要是第二個）獲得了 Paxos 演算法。

      批准 value 的過程中，首先 proposers 將 value 傳送給 acceptors，之後 acceptors 對 value 進行接受（accept）。為了滿足只批准一個 value 的約束，要求經“多數派（majority）”接受的 value 成為正式的決議（稱為“批准”決議）。這是因為無論是按照人數還是按照權重劃分，兩組“多數派”至少有一個公共的 acceptor，如果每個 acceptor 只能接受一個 value，約束2就能保證。

     於是產生了一個顯而易見的新約束：

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

    注意 P1 是不完備的。如果恰好一半 acceptor 接受的提案具有 value A，另一半接受的提案具有 value B，那麼就無法形成多數派，無法批准任何一個 value。

   約束2並不要求只批准一個提案，暗示可能存在多個提案。只要提案的 value 是一樣的，批准多個提案不違背約束2。於是可以產生約束 P2：

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

  注：通過某種方法可以為每個提案分配一個編號，在提案之間建立一個全序關係，所謂“之後”都是指所有編號更大的提案。

 如果 P1 和 P2 都能夠保證，那麼約束2就能夠保證。

批准一個 value 意味著多個 acceptor 接受（accept）了該 value。因此，可以對 P2 進行加強：

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

由於通訊是非同步的，P2a 和 P1 會發生衝突。如果一個 value 被批准後，一個 proposer 和一個 acceptor 從休眠中甦醒，前者提出一個具有新的 value 的提案。根據 P1，後者應當接受，根據 P2a，則不應當接受，這中場景下 P2a 和 P1 有矛盾。於是需要換個思路，轉而對 proposer 的行為進行約束：

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

由於 acceptor 能接受的提案都必須由 proposer 提出，所以 P2b 蘊涵了 P2a，是一個更強的約束。

但是根據 P2b 難以提出實現手段。因此需要進一步加強 P2b。

假設一個編號為 m 的 value v 已經獲得批准（chosen），來看看在什麼情況下對任何編號為 n（n>m）的提案都含有 value v。因為 m 已經獲得批准（chosen），顯然存在一個 acceptors 的多數派 C，他們都接受（accept）了v。考慮到任何多數派都和 C 具有至少一個公共成員，可以找到一個蘊涵 P2b 的約束 P2c：

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

可以用數學歸納法證明 P2c 蘊涵 P2b：

假設具有value v的提案m獲得批准，當n=m+1時，採用反證法，假如提案n不具有value v，而是具有value w，根據P2c，則存在一個多數派S1，要麼他們中沒有人接受過編號小於n的任何提案，要麼他們已經接受的所有編號小於n的提案中編號最大的那個提案是value w。由於S1和通過提案m時的多數派C之間至少有一個公共的acceptor，所以以上兩個條件都不成立，匯出矛盾從而推翻假設，證明了提案n必須具有value v；

若（m+1）..（N-1）所有提案都具有value v，採用反證法，假如新提案N不具有value v，而是具有value w',根據P2c，則存在一個多數派S2，要麼他們沒有接受過m..（N-1）中的任何提案，要麼他們已經接受的所有編號小於N的提案中編號最大的那個提案是value w'。由於S2和通過m的多數派C之間至少有一個公共的acceptor，所以至少有一個acceptor曾經接受了m，從而也可以推出S2中已接受的所有編號小於n的提案中編號最大的那個提案的編號範圍在m..（N-1）之間，而根據初始假設，m..（N-1）之間的所有提案都具有value v，所以S2中已接受的所有編號小於n的提案中編號最大的那個提案肯定具有value v，匯出矛盾從而推翻新提案n不具有value v的假設。根據數學歸納法，我們證明了若滿足P2c，則P2b一定滿足。

P2c是可以通過訊息傳遞模型實現的。另外，引入了P2c後，也解決了前文提到的P1不完備的問題。

        2.演算法的內容

           要滿足P2c的約束，proposer提出一個提案前，首先要和足以形成多數派的acceptors進行通訊，獲得他們進行的最近一次接受（accept）的提案（prepare過程），之後根據回收的資訊決定這次提案的value，形成提案開始投票。當獲得多數acceptors接受（accept）後，提案獲得批准（chosen），由proposer將這個訊息告知learner。這個簡略的過程經過進一步細化後就形成了Paxos演算法。

           在一個paxos例項中，每個提案需要有不同的編號，且編號間要存在全序關係。可以用多種方法實現這一點，例如將序數和proposer的名字拼接起來。如何做到這一點不在Paxos演算法討論的範圍之內。

            如果一個沒有chosen過任何proposer提案的acceptor在prepare過程中回答了一個proposer針對提案n的問題，但是在開始對n進行投票前，又接受（accept）了編號小於n的另一個提案（例如n-1），如果n-1和n具有不同的value，這個投票就會違背P2c。因此在prepare過程中，acceptor進行的回答同時也應包含承諾：不會再接受（accept）編號小於n的提案。這是對P1的加強：

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

         現在已經可以提出完整的演算法了。

         決議的提出與批准

        通過一個決議分為兩個階段：

            prepare階段：proposer選擇一個提案編號n並將prepare請求傳送給acceptors中的一個多數派；acceptor收到prepare訊息後，如果提案的編號大於它已經回覆的所有prepare訊息(回覆訊息表示接受accept)，則acceptor將自己上次接受的提案回覆給proposer，並承諾不再回復小於n的提案；

          批准階段：當一個proposer收到了多數acceptors對prepare的回覆後，就進入批准階段。它要向回覆prepare請求的acceptors傳送accept請求，包括編號n和根據P2c決定的value（如果根據P2c沒有已經接受的value，那麼它可以自由決定value）。

在不違背自己向其他proposer的承諾的前提下，acceptor收到accept請求後即批准這個請求。

這個過程在任何時候中斷都可以保證正確性。例如如果一個proposer發現已經有其他proposers提出了編號更高的提案，則有必要中斷這個過程。因此為了優化，在上述prepare過程中，如果一個acceptor發現存在一個更高編號的提案，則需要通知proposer，提醒其中斷這次提案。

例項

用實際的例子來更清晰地描述上述過程：

有A1, A2, A3, A4, A5 5位議員，就稅率問題進行決議。議員A1決定將稅率定為10%,因此它向所有人發出一個草案。這個草案的內容是：

現有的稅率是什麼?如果沒有決定，則建議將其定為10%.時間：本屆議會第3年3月15日;提案者：A1

在最簡單的情況下，沒有人與其競爭;資訊能及時順利地傳達到其它議員處。

於是, A2-A5迴應：

我已收到你的提案，等待最終批准

而A1在收到2份回覆後就釋出最終決議：

稅率已定為10%,新的提案不得再討論本問題。

這實際上退化為二階段提交協議。

現在我們假設在A1提出提案的同時, A5決定將稅率定為20%:

現有的稅率是什麼?如果沒有決定，則建議將其定為20%.時間：本屆議會第3年3月15日;提案者：A5

草案要通過侍從送到其它議員的案頭. A1的草案將由4位侍從送到A2-A5那裡。現在，負責A2和A3的侍從將草案順利送達，負責A4和A5的侍從則不上班. A5的草案則順利的送至A4和A3手中。

現在, A1, A2, A3收到了A1的提案; A4, A3, A5收到了A5的提案。按照協議, A1, A2, A4, A5將接受他們收到的提案，侍從將拿著

我已收到你的提案，等待最終批准

的回覆回到提案者那裡。

而A3的行為將決定批准哪一個。

情況一[編輯]

假設A1的提案先送到A3處，而A5的侍從決定放假一段時間。於是A3接受並派出了侍從. A1等到了兩位侍從，加上它自己已經構成一個多數派，於是稅率10%將成為決議. A1派出侍從將決議送到所有議員處：

稅率已定為10%,新的提案不得再討論本問題。

A3在很久以後收到了來自A5的提案。由於稅率問題已經討論完畢，他決定不再理會。但是他要抱怨一句：

稅率已在之前的投票中定為10%,你不要再來煩我!

這個回覆對A5可能有幫助，因為A5可能因為某種原因很久無法與與外界聯絡了。當然更可能對A5沒有任何作用，因為A5可能已經從A1處獲得了剛才的決議。

情況二[編輯]

依然假設A1的提案先送到A3處，但是這次A5的侍從不是放假了，只是中途耽擱了一會。這次, A3依然會將"接受"回覆給A1.但是在決議成型之前它又收到了A5的提案。這時協議有兩種處理方式：

1.如果A5的提案更早，按照傳統應該由較早的提案者主持投票。現在看來兩份提案的時間一樣（本屆議會第3年3月15日）。但是A5是個惹不起的大人物。於是A3回覆：

我已收到您的提案，等待最終批准，但是您之前有人提出將稅率定為10%,請明察。

於是, A1和A5都收到了足夠的回覆。這時關於稅率問題就有兩個提案在同時進行。但是A5知道之前有人提出稅率為10%.於是A1和A5都會向全體議員廣播：

 稅率已定為10%,新的提案不得再討論本問題。

一致性得到了保證。

2. A5是個無足輕重的小人物。這時A3不再理會他, A1不久後就會廣播稅率定為10%.

情況三[編輯]

在這個情況中，我們將看見，根據提案的時間及提案者的權勢決定是否應答是有意義的。在這裡，時間和提案者的權勢就構成了給提案編號的依據。這樣的編號符合"任何兩個提案之間構成偏序"的要求。

A1和A5同樣提出上述提案，這時A1可以正常聯絡A2和A3; A5也可以正常聯絡這兩個人。這次A2先收到A1的提案; A3則先收到A5的提案. A5更有權勢。

在這種情況下，已經回答A1的A2發現有比A1更有權勢的A5提出了稅率20%的新提案，於是回覆A5說：

我已收到您的提案，等待最終批准。

而回復了A5的A3發現新的提案者A1是個小人物，不予理會。

A1沒有達到多數，A5達到了，於是A5將主持投票，決議的內容是A5提出的稅率20%.

如果A3決定平等地對待每一位議員，對A1做出"你之前有人提出將稅率定為20%"的回覆，則將造成混亂。這種情況下A1和A5都將試圖主持投票，但是這次兩份提案的內容不同。

這種情況下, A3若對A1進行回覆，只能說：

有更大的人物關注此事，請等待他做出決定。

另外，在這種情況下, A4與外界失去了聯絡。等到他恢復聯絡，並需要得知稅率情況時，他（在最簡單的協議中）將提出一個提案：

現有的稅率是什麼?如果沒有決定，則建議將其定為15%.時間：本屆議會第3年4月1日;提案者：A4

這時，（在最簡單的協議中）其他議員將會回覆：

稅率已在之前的投票中定為20%,你不要再來煩我!

決議的釋出

一個顯而易見的方法是當acceptors批准一個value時，將這個訊息傳送給所有learner。但是這個方法會導致訊息量過大。

由於假設沒有Byzantine failures，learners可以通過別的learners獲取已經通過的決議。因此acceptors只需將批准的訊息傳送給指定的某一個learner，其他learners向它詢問已經通過的決議。這個方法降低了訊息量，但是指定learner失效將引起系統失效。

因此acceptors需要將accept訊息傳送給learners的一個子集，然後由這些learners去通知所有learners。

但是由於訊息傳遞的不確定性，可能會沒有任何learner獲得了決議批准的訊息。當learners需要了解決議通過情況時，可以讓一個proposer重新進行一次提案。注意一個learner可能兼任proposer。

 Progress的保證

根據上述過程當一個proposer發現存在編號更大的提案時將終止提案。這意味著提出一個編號更大的提案會終止之前的提案過程。如果兩個proposer在這種情況下都轉而提出一個編號更大的提案，就可能陷入活鎖，違背了Progress的要求。這種情況下的解決方案是選舉出一個leader，僅允許leader提出提案。但是由於訊息傳遞的不確定性，可能有多個proposer自認為自己已經成為leader。Lamport在The Part-Time Parliament一文中描述並解決了這個問題