分散式系統理論進階7：Paxos變種和優化

本文轉自： https://www.cnblogs.com/bangerlee/p/6189646.html

本系列文章將整理到我在GitHub上的《Java面試指南》倉庫，更多精彩內容請到我的倉庫裡檢視

https://github.com/h2pl/Java-Tutorial

喜歡的話麻煩點下Star哈

文章首發於我的個人部落格：

www.how2playlife.com

該系列博文會告訴你什麼是分散式系統，這對後端工程師來說是很重要的一門學問，我們會逐步瞭解分散式理論中的基本概念，常見演算法、以及一些較為複雜的分散式原理，同時也需要進一步瞭解zookeeper的實現，以及CAP、一致性原理等一些常見的分散式理論基礎，以便讓你更完整地瞭解分散式理論的基礎，為後續學習分散式技術內容做好準備。

如果對本系列文章有什麼建議，或者是有什麼疑問的話，也可以關注公眾號【Java技術江湖】聯絡作者，歡迎你參與本系列博文的創作和修訂。

引言

《分散式系統理論進階 - Paxos》中我們瞭解了Basic Paxos、Multi Paxos的基本原理，但如果想把Paxos應用於工程實踐，瞭解基本原理還不夠。

有很多基於Paxos的優化，在保證一致性協議正確(safety)的前提下，減少Paxos決議通訊步驟、避免單點故障、實現節點負載均衡，從而降低時延、增加吞吐量、提升可用性，下面我們就來了解這些Paxos變種。

Multi Paxos

首先我們來回顧一下Multi Paxos，Multi Paxos在Basic Paxos的基礎上確定一系列值，其決議過程如下：

phase1a: leader提交提議給acceptor

phase1b: acceptor返回最近一次接受的提議(即曾接受的最大的提議ID和對應的value)，未接受過提議則返回空

phase2a: leader收集acceptor的應答，分兩種情況處理

　　phase2a.1: 如果應答內容都為空，則自由選擇一個提議value

　　phase2a.2: 如果應答內容不為空，則選擇應答裡面ID最大的提議的value

phase2b: acceptor將決議同步給learner

Multi Paxos中leader用於避免活鎖，但leader的存在會帶來其他問題，一是如何選舉和保持唯一leader(雖然無leader或多leader不影響一致性，但影響決議程式progress)，二是充當leader的節點會承擔更多壓力，如何均衡節點的負載。Mencius ^[1]提出節點輪流擔任leader，以達到均衡負載的目的；租約(lease)可以幫助實現唯一leader，但leader故障情況下可導致服務短期不可用。

Fast Paxos

在Multi Paxos中，proposer -> leader -> acceptor -> learner，從提議到完成決議共經過3次通訊，能不能減少通訊步驟？

對Multi Paxos phase2a，如果可以自由提議value，則可以讓proposer直接發起提議、leader退出通訊過程，變為proposer -> acceptor -> learner，這就是Fast Paxos ^[2]的由來。

Multi Paxos裡提議都由leader提出，因而不存在一次決議出現多個value，Fast Paxos裡由proposer直接提議，一次決議裡可能有多個proposer提議、出現多個value，即出現提議衝突(collision)。leader起到初始化決議程式(progress)和解決衝突的作用，當衝突發生時leader重新參與決議過程、回退到3次通訊步驟。

Paxos自身隱含的一個特性也可以達到減少通訊步驟的目標，如果acceptor上一次確定(chosen)的提議來自proposerA，則當次決議proposerA可以直接提議減少一次通訊步驟。如果想實現這樣的效果，需要在proposer、acceptor記錄上一次決議確定(chosen)的歷史，用以在提議前知道哪個proposer的提議上一次被確定、當次決議能不能節省一次通訊步驟。

EPaxos

除了從減少通訊步驟的角度提高Paxos決議效率外，還有其他方面可以降低Paxos決議時延，比如Generalized Paxos ^[3]提出不衝突的提議(例如對不同key的寫請求)可以同時決議、以降低Paxos時延。

更進一步地，EPaxos ^[4](Egalitarian Paxos)提出一種既支援不衝突提議同時提交降低時延、還均衡各節點負載、同時將通訊步驟減少到最少的Paxos優化方法。

為達到這些目標，EPaxos的實現有幾個要點。一是EPaxos中沒有全域性的leader，而是每一次提議發起提議的proposer作為當次提議的leader(command leader)；二是不相互影響(interfere)的提議可以同時提交；三是跳過prepare，直接進入accept階段。EPaxos決議的過程如下：

左側展示了互不影響的兩個update請求的決議過程，右側展示了相互影響的兩個update請求的決議。Multi Paxos、Mencius、EPaxos時延和吞吐量對比：

為判斷決議是否相互影響，實現EPaxos得記錄決議之間的依賴關係。

小結

以上介紹了幾個基於Paxos的變種，Mencius中節點輪流做leader、均衡節點負載，Fast Paxos減少一次通訊步驟，Generalized Paxos允許互不影響的決議同時進行，EPaxos無全域性leader、各節點平等分擔負載。

優化無止境，對Paxos也一樣，應用在不同場景和不同範圍的Paxos變種和優化將繼續不斷出現。

[1] Mencius: Building Efficient Replicated State Machines for WANs, Yanhua Mao,Flavio P. Junqueira,Keith Marzullo, 2018

[2] Fast Paxos, Leslie Lamport, 2005

[3] Generalized Consensus and Paxos, Leslie Lamport, 2004

[4] There Is More Consensus in Egalitarian Parliaments, Iulian Moraru, David G. Andersen, Michael Kaminsky, 2013