一、簡介
Paxos 協議是少數在工程實踐中證實的強一致性、高可用的去中心化分布式協議，Google 的很多大型分布式系統都采用了 Paxos 演算法來解決分布式一致性問題，如 Chubby、Megastore 以及 Spanner 等，開源的 ZooKeeper 以及 MySQL 5.7 推出的用來取代傳統的主從復制的 MySQL Group Replication 等紛紛采用 Paxos 演算法解決分布式一致性問題，
Paxos 協議的流程較為復雜，但其基本思想卻不難理解，類似于人類社會的投票程序，Paxos 協議中，有一組完全對等的參與節點，這組節點各自就某一事件做出決議，如果某個決議獲得了超過半數節點的同意則生效，Paxos 協議中只要有超過一半的節點正常，就可以作業，能很好對抗宕機、網路分化等例外情況，
二、協議角色
Proposer：提案者，Proposer 可以有多個，Proposer 提出議案（value），所謂 value，在工程中可以是任何操作，例如“修改某個變數的值為某個值”、“設定當前 primary 為某個節點”等等， Paxos協議中統一將這些操作抽象為 value，同一輪 Paxos程序，最多只有一個 value 被批準，
Acceptor：批準者，Acceptor 有 N 個，Proposer 提出的 value 必須獲得超過半數（N/2+1）的 Acceptor 批準后才能通過，Acceptor 之間完全對等獨立，
Learner：學習者，不參與決策，學習被批準的 value（即獲得 N/2 + 1 的 Acceptor 批準），所謂學習就是通過讀取各個 Proposer/Acceptor 對 value 的選擇結果，如果某個 value 被超過半數 Proposer 通過，則 Learner 學習到了這個 value，
上述三類角色只是邏輯上的劃分，實踐中一個節點可以同時充當這三類角色，
三、協議流程
Paxos 演算法解決的核心問題正是分布式一致性問題，即一個分布式系統中的各個行程如何就某個值（決議）達成一致，
Paxos 協議一輪一輪的進行，每輪都有一個編號，每輪 Paxos 協議可能會批準一個 value，也可能無法批準一個 value， 如果某一輪 Paxos 協議批準了某個 value，則以后各輪 Paxos 只能批準這個 value （這是整個協議正確性的基礎），
上述各輪協議流程組成了一個 Paxos 協議實體，即一次 Paxos 協議實體只能批準一個 value，這也是 Paxos 協議強一致性的重要體現，
每輪 Paxos 協議分為準備階段和批準階段，在這兩個階段 Proposer 和 Acceptor 有各自的處理流程：
基本例子
基本例子里有 5 個 Acceptor， 1 個 Proposer，不存在任何網路、宕機例外，我們著重考察各個Accpetor 上變數 B 和變數 V 的變化，及 Proposer 上變數 b 的變化，
1、初始狀態
| Acceptor 1 | Acceptor 2 | Acceptor 3 | Acceptor 4 | Acceptor 5 | |
|---|---|---|---|---|---|
| B | 0 | 0 | 0 | 0 | 0 |
| V | NULL | NULL | NULL | NULL | NULL |
| Proposer1 | |
|---|---|
| b | 1 |
2、Proposer 向所有 Accpetor 發送“Prepare(1)”，所有 Acceptor 正確處理，并回復 Promise(1, NULL)
| Acceptor 1 | Acceptor 2 | Acceptor 3 | Acceptor 4 | Acceptor 5 | |
|---|---|---|---|---|---|
| B | 1 | 1 | 1 | 1 | 1 |
| V | NULL | NULL | NULL | NULL | NULL |
| Proposer1 | |
|---|---|
| b | 1 |
3、Proposer 收到 5 個 Promise(1, NULL)，滿足多余半數的 Promise 的 value 為空，此時發送Accept(1, v1)，其中 v1 是 Proposer 選擇的 value，
| Acceptor 1 | Acceptor 2 | Acceptor 3 | Acceptor 4 | Acceptor 5 | |
|---|---|---|---|---|---|
| B | 1 | 1 | 1 | 1 | 1 |
| V | v1 | v1 | v1 | v1 | v1 |
4、此時，v1 被超過半數的 Acceptor 批準，v1 即是本次 Paxos 協議實體批準的 value，這里解釋下為什么被批準的 value 無法改變，因為 v1 目前已經被超半數的 Acceptor 通過，即使再發起下一輪選舉，也必須有三個 Promise（b，v1）才有可能通過，即被批準的 v1 無法改變，如果 Learner學習 value，學到的只能是 v1，
四、Multi-Paxos 演算法
Paxos 協議引入了輪數的概念，高輪數的 Paxos 提案可以搶占低輪數的 Paxos 提案，從而避免了死鎖的發生，然而這種設計卻引入了“活鎖”的可能，即 Proposer 相互不斷以更高的輪數提出議案，使得每輪 Paxos程序都無法最終完成，從而無法批準任何一個value，Multi-Paxos 正是為解決此問題而提出，Multi-Paxos 基于Basic Paxos 做了兩點改進：
- 針對每一個要確定的值，運行一次 Paxos 演算法實體（Instance），形成決議，每一個 Paxos 實體使用唯一的 Instance ID 標識，
- 在所有 Proposers 中選舉一個 Leader，由 Leader 唯一的提交 Proposal 給 Acceptors 進行表決，這樣沒有 Proposer 競爭，解決了活鎖問題，在系統中僅有一個 Leader 進行 value 提交的情況下，Prepare 階段就可以跳過，從而將兩階段變為一階段，提高效率，
Multi-Paxos 首先需要選舉 Leader，Leader 的確定也是一次決議的形成，所以可執行一次 Basic Paxos 實體來選舉出一個 Leader，選出 Leader 之后只能由 Leader 提交 Proposal，在 Leader 宕機之后服務臨時不可用，需要重新選舉 Leader 繼續服務，在系統中僅有一個 Leader 進行 Proposal 提交的情況下，Prepare 階段可以跳過，
Multi-Paxos 通過改變 Prepare 階段的作用范圍至后面 Leader 提交的所有實體，從而使得 Leader 的連續提交只需要執行一次 Prepare 階段，后續只需要執行 Accept 階段，將兩階段變為一階段，提高了效率，為了區分連續提交的多個實體，每個實體使用一個 Instance ID 標識，Instance ID 由 Leader 本地遞增生成即可，
Multi-Paxos 允許有多個自認為是 Leader 的節點并發提交 Proposal 而不影響其安全性，這樣的場景即退化為 Basic Paxos，
Chubby 和 Boxwood 均使用 Multi-Paxos，ZooKeeper 使用的 Zab 也是 Multi-Paxos 的變形，
參考資料：
- 《分布式系統原理介紹》
- Paxos演算法詳解
- 分布式系列文章——Paxos演算法原理與推導
轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/274668.html
標籤：其他