自從lamport在2023年發表paxos演算法後，對paxos的各種改進工作就從未停止，其中動作最大的莫過於2023年發表的fast paxos。無論何種改進，其重點依然是在訊息延遲與效能、吞吐量之間作出各種權衡。為了容易地從概念上區分二者，稱前者classic paxos，改進後的後者為fast paxos。
lamport在40多頁的**中不僅提出了fast paxos演算法，並且還從工程實踐的角度重新描述了paxos，使其更貼近應用場景。從一般的client/server來考慮，client其實承擔了proposer和learner的作用，而server則扮演acceptor的角色，因此下面重新描述了paxos演算法中的幾個角色：
就是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便是基於此而產生。
我們再回顧下classic paxos的幾個階段：
很明顯，在phase2a.1中，如果leader可以自由決定乙個value，則可以讓proposer提交這個value，自己則退出通訊過程。只要之後的過程執行正常，leader始終不參與通訊，一直有proposer直接提交value到acceptor，從而把classic paxos的三階段通訊減少為兩階段，這便是fast paxos的由來。因此，我們更加形式化下fast paxos的幾個階段：
演算法主要變化在phase2a階段，即：
先不考慮實現，從形式上訊息僅需在proposer-----acceptor-----learner之間傳遞即可，也即僅需2個通訊步驟。下面我們詳細說明演算法過程：
在正常情況下，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的互動圖：
在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，rv,rw。
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將無法得知投票結果因此如果保證下面兩個條件：
則v、w不可能同時被選擇
根據上面描述，為了防止一次fast round選擇多個value，quorum需要滿足下面兩個條件：
不妨設總acceptor數為n，classic round執行的最大失敗acceptor數為f，fast round允許的失敗數為e，即n-f構成classic round的乙個quorum，n-e構成fast round的乙個quorum。
上面兩個條件等價於：
設qc,qf分別為classic和fast round的quorum大小，經過整理可得兩個下限結果：
|qc| = |qf| ≥ n − ⌈n/3⌉ + 1 ≥ ⌊2n/3⌋ + 1
|qc| ≥n-⌈n/2⌉+1 = ⌈n/2⌉+1
|qf|≥n-⌈n/4⌉≥⌈3n/4⌉
證明請參考：一致性演算法中的節點下限
作為優化，acceptor在投票value時也應該傳送到leader，這樣leader就很容易能發現衝突。leader如果在round i發現衝突，可以很容易地開始roun i+1，從phase1a開始重新執行classic paxos過程，但這個其實可以進一步優化，我們首先考慮下面這個事實：
如果leader重啟了round i+1，並且收到了i-quorum個acceptor傳送的phase1b訊息，則該訊息明確了兩件事情：
假如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，搞的過於複雜。
至此，再完整地總結下fast paxos的progress：
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的各種簡化形式
**：
Paxos 演算法簡介
拜占庭將軍問題 byzantine failure 是由萊斯利 蘭伯特提出的點對點通訊中的基本問題。意思就是，在存在訊息丟失的不可靠的通道上保證資訊的一致性是不可能的。所以在一般討論一致性的問題上時，比如paxos 演算法，都先假定不會存在拜占庭問題。paxos 是乙個分布式一致性演算法。主要解決的...
Paxos演算法 前世
paxos演算法是基於訊息傳遞且具有高度容錯特性的一致性演算法。我們將從乙個簡單的問題開始，逐步的改進我們的設計方案，最終得到paxos，乙個可以在逆境下工作的協議。一 客戶端 伺服器模型 我們從最小的分布式系統開始，在這個系統中，只有兩個結點，客戶端結點與服務端結點，客戶端結點能夠操作 儲存或更新...
Paxos協議筆記
對paxos協議的介紹，可以通過leslie lamport的 paxos made 展開學習和了解。paxos演算法在允許失敗的分布式系統環境下，實現系統一致性。失敗的情況有很多，譬如由於網路問題導致的通訊資料丟失，參與paxos演算法的機器宕機等情況。paxos演算法將分布式系統一致性問題進行抽...