寫一寫關於Paxos和我的理解

這個文章是一年前看Paxos的時候自己的一些筆記和思考。有些翻譯自wiki和原論文Paxos Made Simple，也有一部分是參考網上能找到並且覺得很棒的博客。文末都貼出了參考出處。

除了這篇還計劃着寫幾篇，包括Paxos具體實現。
才疏學淺，如果覺得文
章有什麼問題歡迎留言討論。

一 相關概念

1.paxos協議是用來解決什麼問題的

paxos協議是用來解決網絡中不可靠服務進程之間的共識問題（consensus），解決共識問題的目的在於使整個系統中的進程達成一致（consistent）
（前面說的說的不可靠是指服務中的任何一個進程都有可能失敗）

2.關於Consensus（共識）

（參考Consensus wiki）
共識問題需要在多個進程（或代理）之間就單個數據值達成一致。（The consensus problem requires agreement among a number of processes (or agents) for a single data value）
要實現一個具有容錯共識協議需要滿足下面三個條件：

• 最終 ，每個正常的進程必須確定一個決議。（Termination：Eventually, every correct process decides some value.）
• 如果所有正常的進程提出了同一個決議v,那麼任何一個正常的進程都應該對該決議做出決策(Integrity: If all the correct processes proposed the same value v, then any correct process must decide v.)
• 所有正常的進程接受的決議必須是同一個（Agreement：Every correct process must agree on the same value）
  上面的幾點都來自wiki, consensus
  但是個人覺得第二點翻譯出來怪怪的
  參考了一下下面PPT中的一些，此外還應該參考下屬PPT中的

2.paxos協議的一些假定

（參考Paxos wiki）
（也即，我們在考慮paxos協議的時候需要關注的問題，以及可以忽略的一些問題）

服務進程

• 服務進程以任意速度運行。
• 服務進程可能會遇到故障。
• 具有穩定存儲的服務進程可能在故障之後重新加入協議（在崩潰恢復故障模型之後）。
• 服務進程不會串通，欺騙或以其他方式試圖破壞協議。（也就是說，拜占庭故障不會發生）

網絡

• 服務進程可以向任何其他進程發送消息。
• 消息以異步方式發送，可能需要很長時間才能完成。
• 消息可能會丟失，重新排序或重複。
• 消息傳遞沒有損壞（也就是說，不會發生拜占庭式的失敗）

服務進程的數量

非故障進程的數量必須嚴格大於錯誤進程的數量（Quorums）。對於服務進程數爲n=2F+1的系統中，如果錯誤進程數不超過F，那麼就可以繼續使用該協議

由於存在上面的條件約束，因此在Paxos實現的時候就需要考慮到多個方面：異步通信，故障恢復。

3.paxos中的角色和概念

• Proposer
• Acceptor
• Learner
  （直接參考下圖就行,圖片來源在文末PDF連接）
  

在一個服務中，同一個進程在不同時間段可能是上述三個角色中任何一個

Proposal Value：提議的值；
Proposal Number：提議編號，可理解爲提議版本號，要求全局不能衝突；

一個提案proposal一般是由（ProposalValue，ProposalNumber)組成

4. paxos的安全性（safety ，或者說一致性consistency）

（參考論文原文）
爲了保證一致性（個人還是覺得用一致性這個詞比較直觀），Paxos定義了三個屬性並確保始終保持它們：

• 約束1：只有value被提出後纔可能被選定chosen，
• 約束2：只有一個value被選定chosen，並且
• 約束3：process永遠不會獲知一個value被選擇了，除非這個valu確實已經被選定chosen。（進程只會獲知到已經確認被選定（Chosen）的值）

二 Basic Paxos

上面的一個大節裏面已經描述了在多個網絡進程組成的系統中，各進程之間爲了達成共識需要滿足的條件，進一步描述了paxos協議中爲了保證一致性（或安全性）做出了哪些基本要求。此外還提及了整個決策過程中可能遇到的問題。
Paxos協議要解決的問題是什麼？
上面的約束中最重要的是約束2，Paxos要達到的目的也就是快速的選定一個value，並且保證這個value被選定之後就不再改變。

1.1 算法的提出

上面paxos的安全性一節中提出的三個屬性是最基本的約束了，在複雜的環境中，上述約束說起來簡單，但是要做到卻很難，所以作者通過不斷加強上述3個約束（主要是第二個）獲得了 Paxos 算法：
其中約束2是最重要的，在一個異步併發通信的環境中，如何保證約束2呢？
一個acceptor接受多個proposal應該有怎麼樣的行爲？
多個proposer異步發送到多個acceptor上？
（畫圖說明）
單點問題？
最簡單的方法就是用單個acceptor代理。Proposer發送議案（proposal）給這個acceptor，它選擇最先收到的議案。儘管簡單，但是如果acceptor停機了，那麼系統就不能繼續運行了，這個方案並不能滿足要求。【明顯的單點問題】
看來我們需要選擇另外的方法，我們用多個acceptor代理，而非一個，proposer向一組acceptor提出議案。一個acceptor可能接受accept該議案，當有足夠大的acceptor集合批准了這個議案時，決議【議案是一個{編號，決議}對】就被選擇了。那麼這個集合多大才足夠呢？爲了保證只有一個決議被選擇，我們可以讓這個集合包含多數的代理【後面也會稱之爲多數派】。因爲任意兩個多數派至少有一個相同的代理，如果一個acceptor最多隻能接受accept一個決議，這就是可行的。
假設沒有失敗或者消息丟失，即使僅有一個proposer提出了一個決議，我們也希望能選擇一個決議。這就導出了下面的需求

如何保證只有一個決議被選擇（約束2）呢？
首先，即使僅有一個proposer提出了一個決議，我們也希望能選定一個決議。這就導出了下面的需求：
P1：一個 acceptor 必須接受（accept）第一次收到的提案。
（但是P1 是不完備的。如果恰好一半 acceptor 接受的提案具有 value A，另一半接受的提案具有 value B，那麼就無法形成多數派，無法批准任何一個 value。因此還需對P1加強）

如果一個議案{n, v}被大多數（majority）的接受accept，那麼決議v就被批准chosen。這種情況下，我們稱議案（包括其決議v）被批准了。
我們允許選擇多個議案，但是必須保證所有選擇的議案包括相同的決議。對議案編號歸納，可以保證
（因爲約束2並不要求只選定chosen一個提案proposal，它只是要求只批准一個value，這就暗示可以存在多個提案。只要提案的 value 是一樣的，批准多個提案不違背約束2。）

P2：一旦一個具有 value v 的提案被選定（chosen），那麼之後選定（chosen）的提案必須具有 value v。
如果 P1 和 P2 都能夠保證，那麼約束2就能夠保證。（不論多少個proposal{value,number}被選定，最終都只是具有相同value的）

選定一個 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。
由於所有提案都是有proposer提出的，只要滿足P2b,即proposer提出的提案都具有value v, 那麼acceptor接受到的提案也就一定具有value v，因此可以說 P2b 蘊涵了 P2a，這也意味着其包含了p2,它是一個更強的約束。

上述P2b是一個很直觀明瞭的約束條件了，但是根據 P2b 難以提出實現手段。因此需要進一步加強 P2b，找到一個便於實現的約束條件。
如果讓你按照上面的約束寫這個程序你能寫出來嗎？或許不能。考慮到具體實現的時候，我們一般步驟是：先提出proposal 再讓acceptor去選定。但是上述幾條約束p2 p2a p2b都是直接假定了提案已經被選定，因此不便於具體代碼實現（他們的出發點都是基於已經存在一個被選定的提案，站在結果上面來做出約束）。我們需要的是一個關於提出proposal的約束條件。
假設一個編號爲 m 的 value v 已經被選定（chosen），來看看在什麼情況下對任何編號爲 n（n>m）的提案都含有 value v。因爲 m 已經被選定（chosen），顯然存在一個 acceptors 的多數派 C，他們都接受（accept）了v。考慮到任何多數派都和 C 具有至少一個公共成員，可以找到一個蘊涵 P2b 的約束 P2c：

P2c：如果一個編號爲 n 的提案具有 value v，那麼存在一個多數派S，要麼S中所有人都沒有接受過（accept）編號小於 n 的任何提案，要麼S中所有人已經接受過（accept）的所有編號小於 n 的提案中編號最大的那個提案的value都是v。
換句話說就是，如果存在一個編號爲 n 的提案具有 value v，那麼只能存在以下兩種情況：

• 編號小於n的任何提案都沒有被S acceptor接受accept， （對應P1）
• 編號小於n的提案中，編號最大的那個提案已經被S acceptor接受的且其值爲value v （對應p2b）

這裏有點繞，建議參考論文原文來理解

for any v and n, if a proposal with value v and number n is issued,then there is a set S consisting of a majority of acceptors such that either (a) no acceptor in S has accepted any proposal numbered less than n, or (b) v is the value of the highest-numbered proposal among all proposals numbered less than n accepted by the acceptors in S.

滿足P2c就能滿足P2b,
爲了滿足P2c（即只出現上述兩種情況），那麼需要我們在準備提出一個編號爲n的提案之前，都要跟acceptor進行通信，來獲知大多數acceptor是否通過了一個編號小於n的提案，如果通過了那麼這個提案的編號和value是多少。
這就引出了兩階段提交：

• prepare階段：（首先跟acceptor通信一下，獲取一下提案情況。如果沒有這個階段的話，那麼如果讓proposer隨便提出提案的話，那麼很可能會違反p2c約束。）
• accept階段：（根據剛上一得到的情況，來確定自己的行爲）

1.2 總結

2.算法的實現

上面一節中一共兩個約束，p1和p2,其中對p2做出多次加強得到了p2c，因此算法的實現就是圍繞p1和p2c。而且從上面的各點約束來看，每個提案的編號應該是全局唯一且有序的。
上面一節中，P2c對proposer倒是做出了很強的約束了，但是對acceptor的約束只有p1：一個 acceptor 必須接受（accept）第一次收到的提案。
那麼對一個accepter提交多個提案，acceptor應該如何應答呢？
假設存在這樣一種情況一個proposer1和proposer2都已經跟大多數acceptor通信，並知道他們現在並未接受任何提案，此proposer1提出提案（n,v1), proposer2提出提案（n-1,v2)，且v1!=v2
（n,v1）先到達，被接受了，之後提案n-1到來，acceptor應該如何應答呢？如果acceptor接受了這個提案，那麼就違反了p2c中的第二中情況。
因此在prepare過程中，acceptor進行的應答的同時也應包含承諾：不會再接受（accept）編號小於n的提案。這是對P1的加強：
P1a：當且僅當acceptor沒有迴應過編號大於n的prepare請求時，acceptor接受（accept）編號爲n的提案。
那麼也就是說，對於編號大於n的提案，在prepare階段，acceptor仍然可以應答。

承諾：

那麼再來考慮上面的情況
假設存在這樣一種情況一個proposer1和proposer2都已經跟大多數acceptor通信，並知道他們現在並未接受任何提案，此proposer1提出提案（n,v1), proposer2提出提案（n+1,v2)，且v1!=v2
（n,v1）先到達，被接受了，之後提案n+1到來，acceptor應該如何應答呢？如果acceptor接受了這個提案，那麼就違反了p2c中的第二中情況。

參考：
https://en.wikipedia.org/wiki/Paxos_(computer_science)
https://en.wikipedia.org/wiki/Consensus_(computer_science)
Paxos Made Simple 論文原文：https://lamport.azurewebsites.net/pubs/paxos-simple.pdf
挺棒的PPT: https://github.com/hedengcheng/tech/blob/master/distributed/PaxosRaft%20%E5%88%86%E5%B8%83%E5%BC%8F%E4%B8%80%E8%87%B4%E6%80%A7%E7%AE%97%E6%B3%95%E5%8E%9F%E7%90%86%E5%89%96%E6%9E%90%E5%8F%8A%E5%85%B6%E5%9C%A8%E5%AE%9E%E6%88%98%E4%B8%AD%E7%9A%84%E5%BA%94%E7%94%A8.pdf
知乎上的討論：
https://www.zhihu.com/question/19787937