自從Lamport在1998年發表Paxos算法后，對Paxos的各種改進工作就從未停止，其中動作最大的莫過于2005年發表的Fast Paxos。無論何種改進，其重點依然是在消息延遲與性能、吞吐量之間作出各種權衡。為了容易地從概念上區分二者，稱前者Classic Paxos，改進后的后者為Fast Paxos。

1. Fast Paxos概覽

Lamport在40多頁的論文中不僅提出了Fast Paxos算法，并且還從工程實踐的角度重新描述了Paxos，使其更貼近應用場景。從一般的Client/Server來考慮，Client其實承擔了Proposer和Learner的作用，而Server則扮演Acceptor的角色，因此下面重新描述了Paxos算法中的幾個角色：

?

• Client/Proposer/Learner：負責提案并執行提案
• Coordinator：Proposer協調者，可為多個，Client通過Coordinator進行提案
• Leader：在眾多的Coordinator中指定一個作為Leader
• Acceptor：負責對Proposal進行投票表決

就是Client的提案由Coordinator進行，Coordinator存在多個，但只能通過其中被選定Leader進行；提案由Leader交由Server進行表決，之后Client作為Learner學習決議的結果。 這種方式更多地考慮了Client/Server這種通用架構，更清楚地注意到了Client既作為Proposer又作為Learner這一事實。 同樣要注意到的是，如果Leader宕機了，為了保證算法的正確性需要一個Leader的選舉算法，但與之前一樣，Lamport并不關心這個Leader選舉算法，他認為可以簡單地通過隨機或超時機制實現。 另外在Classic Paxos中，從每次Proposer提案到決議被學習，需要三個通信步驟： Proposer-----Leader-----Acceptor-----Learner 從直觀上來說，Proposer其實更“知道”提交那個Value，如果能讓Proposer直接提交value到Acceptor，則可以把通信步驟減少到2個。Fast Paxos便是基于此而產生。

2. Make Paxos Faster

我們再回顧下Classic Paxos的幾個階段：

• Phase1a：Leader提交proposal到Acceptor
• Phase2b：Acceptor回應已經參與投票的最大Proposer編號和選擇的Value
• Phase2a：Leader收集Acceptor的返回值
  Phase2a.1：如果Acceptor無返回值，則自由決定一個
  Phase2a.2： 如果有返回值，則選擇Proposer編號最大的一個
• Phase2b：Acceptor把表決結果發送到Learner

很明顯，在Phase2a.1中，如果Leader可以自由決定一個Value，則可以讓Proposer提交這個Value，自己則退出通信過程。只要之后的過程運行正常，Leader始終不參與通信，一直有Proposer直接提交Value到Acceptor，從而把Classic Paxos的三階段通信減少為兩階段，這便是Fast Paxos的由來。因此，我們更加形式化下Fast Paxos的幾個階段：

• Phase1a：與之前相同
• Phase1b：與之前相同
• Phase2a：Leader收集Acceptor的返回值
  Phase2a.1：如果Acceptor無返回值，則發送一個Any消息給Acceptor，之后Acceptor便等待Proposer提交Value
  Phase2a.2：如果有返回值，則根據規則選取一個
• Phase2b：Acceptor把表決結果發送到Learner（包括Leader）

算法主要變化在Phase2a階段，即：

• 若Leader可以自由決定一個Value，則發送一條Any消息，Acceptor便等待Proposer提交Value
• 若Acceptor有返回值，則Acceptor需選擇某個Value

先不考慮實現，從形式上消息僅需在Proposer-----Acceptor-----Learner之間傳遞即可，也即僅需2個通信步驟。下面我們詳細說明算法過程：

3 一些定義

• Quorum
  在Classic Paxos中一直通過多數派（Majority）來保證算法的正確性，對多數派再進一步抽象化，稱為“Quorum”，要求任意兩個Quorum之間有交集（從而間接表達了majority的含義）
• Round
  在Classic Paxos中，Proposer每次提案都用一個全序的編號表示，如果執行順利，該編號的Proposal在經歷Phase1，Phase2后最終會執行成功。
  在Fast Paxos稱這個帶編號的Proposal的執行過程為“Round”
• i-Quorum
  在Classic Paxos執行過程中，一般不會明確區分每次Round執行的Quorum，雖然也可以為每個Round指定一個Quorum。在Fast Paxos中會通過i-Quorum明確指定Round i需要的Quorum
• Classic Round
  執行Classic Paxos的Round稱為Classic Round
• Fast Round
  如果Leader發送了Any消息，則認為后續通信是一個Fast Round；若Leader未發送Any消息，還是跟之前一樣通信，則后續行為仍然是Classic Round。
  根據Lamport描述，Classic Round和Fast Round可通過Round Number進行加以區分。

4 Any消息

在正常情況下，Leader若可以自由決定一個Value，應該發生一條Phase2a消息，其中包含了選擇的Value，但此時卻發送了一條無Value的Any消息。Acceptor在接收到Any消息后可做一些開始Fast Round的初始化工作，等待Proposer提交真正的Value。Any消息的意思是Acceptor可以做任意的處理。 因此，一個Fast Round包括兩個階段：由Any消息開始的階段，和由Proposer提交Value的結束階段，而Leader只是起到一個初始化過程的作用，如果沒有錯誤發生，Leader將退出之后的通信中過程。 下面是Classic Paxos交互圖： 下面是Fast Paxos的交互圖：

5 沖突

在Classic Paxos中，Acceptor投票的value都是Leader選擇好的，所以不存在同一Round中投票多個Value的場景，從而保證了一致性。但在Fast Round中因為允許多個Proposer同時提交不同的Value到Acceptor，這將導致在Fast Round中沒有任何value被作為最終決議，這也稱為“沖突”（Collision） Proposer提交的Round是全序的，不同的Proposer提交的Round肯定不一樣，同一Proposer不可能在同一Round中提交不同的Value，那為什么還會有同一Fast Round中有多個Value的情況？原因在于Fast Round與Round區別，當Fast Round開始后，會被分配一個唯一的Round Number，之后無論多少個Proposer提交Value都是基于這個Round Number，而不管Proposer提交的Round是否全序。 比如，Fast Round Number為10，Proposer1提交了（11，1），Proposer2提交了（12，2），但對Fast Round來說存在（10，1，2）兩個Value。 因為沖突的存在，會導致Phase2a.2的選擇非常困難，原因是： 在Classic Paxos中，如果Acceptor返回多個Value，只要排序，選擇最高的編號對應的Value即可，因為Classic Paxos中的Value都是有Leader選擇后在Phase2a中發送的，因此最高編號的Value肯定只有一個。但在Fast Paxos中，最高編號的Value會發現多個，比如（10，1，2）。 假如當前Leader正在執行第i個Classic Round(i-Quorum為Q) ，得到Acceptor反饋的最高編號為k，有兩個value：v、w，說明Fast Round k存在兩個k-Quorum，R_v,R_w。 O4(v)：下面定義在Round k中v或w被選擇的條件： 如果v在Round k中被選擇，那么存在一個k-Quorum R，使得對任意的Acceptor a∈Q∩R，都對v作出投票。 這個問題也可表述為：R中的所有Acceptor都對v作出投票，并且Q∩R≠φ，因為如果Q∩R=φ，則Round i將無法得知投票結果 因此如果保證下面兩個條件：

• 每個Acceptor在同一Fast Round中僅投票一個Value
• Q∩R_v∩R_w≠φ

則v、w不可能同時被選擇

6 確定Quorum

根據上面描述，為了防止一次Fast Round選擇多個Value，Quorum需要滿足下面兩個條件：

• 任意兩個Classic Quorum有交集
• 任意一個Classic Quorum與任意兩個Fast Quorum有交集

不妨設總Acceptor數為N，Classic Round運行的最大失敗Acceptor數為F，Fast Round允許的失敗數為E，即N-F構成Classic Round的一個Quorum，N-E構成Fast Round的一個Quorum。 上面兩個條件等價于：

• N>2F
• N>2E+F

設Q_c,Q_f分別為Classic和Fast Round的Quorum大小，經過整理可得兩個下限結果：

|Q_c| = |Q_f| ≥ N ? ?N/3? + 1 ≥ ?2N/3? + 1

|Q_c| ≥N-?N/2?+1 = ?N/2?+1
|Q_f|≥N-?N/4?≥?3N/4?

證明請參考：一致性算法中的節點下限

7 沖突Recovery

作為優化，Acceptor在投票Value時也應該發送到Leader，這樣Leader就很容易能發現沖突。Leader如果在Round i發現沖突，可以很容易地開始Roun i+1，從Phase1a開始重新執行Classic Paxos過程，但這個其實可以進一步優化，我們首先考慮下面這個事實： 如果Leader重啟了Round i+1，并且收到了i-Quorum個Acceptor發送的Phase1b消息，則該消息明確了兩件事情：

• 報告Acceptor a參與投票的最大Round和對應的Value
• 承諾不會對小于i+1的Round作出投票

假如Acceptor a也參與了Round i的投票，則a的Phase1b消息同樣明確了上述兩件事情，并且會把對應的Round，Value在Phase2b中發送給Leader（當然還有Learner），一旦Acceptor a執行了Phase2b，則也同時表明a將不會再對小于i+1的Round進行投票。 也就是說，Round i的Phase2b與Round i+1的Phase1b有同樣的含義，也暗含著如果Leader收到了Round i的Phase2b，則可直接開始Round i+1的Phase2a。經過整理，產生了兩種解決沖突(Recovery)的方法：

7.1 基于協調者的Recovery

如果Leader在Round i 中收到了(i+1)-Quorum個Acceptor的Phase2b消息，并且發現沖突，則根據O4(v)選取一個value，直接執行Round i+1的Phase2a；否則，從Phase1a開始重新執行Round i+1

7.2 基于非協調的Recovery

作為基于協調Recovery的擴展，非協調要求Acceptor把Phase2b消息同時發送給其他Quorum Acceptor，由每個Acceptor直接執行Round i+1的Phase2a，但這要求i-Quorum與(i+1)-Quorum必須相同，并且遵循相同選擇value的規則。 這種方式的好處是Acceptor直接執行Round i+1的Phase2a，無需經過Leader，節省了一個通信步驟，缺點是Acceptor同時也作為Proposer，搞的過于復雜。

8 Fast Paxos Progress

至此，再完整地總結下Fast Paxos的Progress：

• Phase1a：與之前相同
• Phase1b：與之前相同
• Phase2a：Leader收集Acceptor的返回值
  Phase2a.1：如果Acceptor無返回值，則發送一個Any消息給Acceptor，之后Acceptor便等待Proposer提交Value
  Phase2a.2：如果有返回值
  ? ? ? 2.1 如果僅存在一個Value，則作為結果提交
  ? ? ? 2.2 如果存在多個Value，則根據O4(v)選取符合條件的一個
  ? ? ? 2.3 如果存在多個結果并且沒有符合O4(v)的Value，則自由決定一個
• Phase2b：Acceptor把表決結果發送到Learner（包括Leader）

9. 總結

Fast Paxos基本是本著樂觀鎖的思路：如果存在沖突，則進行補償。其中Leader起到一個初始化Progress和解決沖突的作用，如果Progress一直執行良好，則Leader將始終不參與一致性過程。 因此Fast Paxos理論上只需要2個通信步驟，而Classic Paxos需要3個，但Fast Paxos在解決沖突時有至少需要1個通信步驟，在高并發的場景下，沖突的概率會非常高，沖突解決的成本也會很大。 另外，Fast Paxos把Client深度引入算法中，致使其架構遠沒Classic Paxos那么清晰，也沒Classic Paxos容易擴展。 還有一點要注意的是，Fast Quorum的大小比Classic的要大，一般Fast Quorum至少需要4個節點(3E+1)，而Classic Paxos需要3個(2F+1)（請參考：一致性算法中的節點下限）。 總之，在我看來Fast Paxos是一個理論上可行，但實際中很難操作的算法，實際中用的比較多的還是Classic Paxos的各種簡化形式

10 參考資料

• Fast Paxos(Lamport 2005)
• Multicoordinated Paxos
• On the Coordinator’s Rule for Fast Paxos
• Classic Paxos vs. Fast Paxos
• http://en.wikipedia.org/wiki/Paxos_(computer_science)

轉載于:https://www.cnblogs.com/kaffeetrinken/p/8490736.html

總結

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

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