Paxos 由著名圖靈獎獲得者Leslie Lamport提出，該算法是分布式一致性算法中的奠基之作，今天初讀此文僅將相關學習心得予以記錄。
1.Paxos 是什么？主要用來解決什么問題？
Paxos是一個用於實現可容錯的分布式系統的算法，主要用於保證分布式集群中多備份系統之間的操作和數據的一致性。這樣集群中的每台機器對外相當於完全一致，從而其互相之間可以互為備份，從而使得系統能夠容忍一定數量的機器出問題（宕機、斷網、硬盤損壞等等）。
2.Paxos的基本原理是什么？
介紹paxos的算法之前，首先介紹一個paxos算法中涉及到的幾個角色：
proposer提出提案者，在實際應用中可以理解為request的接受者，該角色接收到用戶請求，並向集群提出提案要求執行該request。acceptor接收者，接收者接收到來自其他的proposer的提案，並按照一定的邏輯決定是否接收當前的提案，也就是是否接收request並准備執行request的角色。learner學習者，能夠從其他節點獲取某個被共識之后的提案。
2.1 paxos解決的問題
假設有n個獨立的進程分別能夠提出一個值，那么pasos算法用於保證這些進程提出的值的其中之一能夠被正確處理。
paxos算法的安全性前提條件為：
- 只有被提議的值才有可能被選中，也就是說不可能有憑空出現的值出現；
- 一次只有一個值會被選中；
- 進程不會learn到一個沒有被選中的值；
ps:這里的選中是翻譯論文中的propose,其實我感覺這里的propose value可以理解為對某個請求的共識，也就是當進程接收到客戶的請求時需要paxos算法保證每次各個進程所處理的請求一致。
pasox算法的關鍵也就是對這種
2.2 paxos算法的論述以及推論
2.2.1 如何選擇一個提案？
對於單個服務器而言，可以按照先到先服務的順序去選擇提案，但是對於多個進程怎么保證提案選擇？提案可以由任何一個proposer發出，每個acceptor收到提案的順序會有所不同，如何保證各個acceptor按同樣的順序接收提案是paxos算法的核心。
為了保證其一直性，paxos給出一系列的接收提案的規定及其推論：
P1: An acceptor must accept the firtst proposal that it receives.（任何接收者都按照先來先服務的原則接收提案。）
P1這個會引起另外一個問題：也就是每個進程接收到的提案順序不一樣，這會造成整個系統的不一致
為了解決這個問題，paxos為每個擬接收的提案（后文直接用Request替代好了）分配一個序號，每個acceptor可以同時接收多個Request,但是一個時間只有一個Request會得到一個序號，序號是遞增的。每個Request分配需要必須要集群中大多數節點同意，這里的大多數由系統的Intersection Quorum決定,本場景中的quorum數最少系統節點數目的一半加1。
P2: If a proposal with value v is choosen, then every higger-numbered proposal that is choosen has value v.(如果某個值v在num k的時候被選中，num 大於k的Proposal中能夠看到之前選中的v的值)
由P1和P2可以得出一個提案提交的算法：
- 某個節點上的Proposer提出一個新的proposal num k，並發送到其他一定數量的acceptor，讓其保證一下兩點：（這被稱為
PrepareRequest(n)n是request的序號）
- 不在接收proposal num < k的提案；
- proposal num 小於k的所有提案已經被accept了；
- 如果該Proposer接收到來自大多數的節點對1中的PrepareRequest的回應，那么Proposer會選擇Responses中的最大的proposal提案序號，如果responders沒有改提案號，Proposer就會自己隨機選擇一個並和之前的k一起發送
AcceptRequest(n, v)到acceptors;
P1a: An acceptor can accept a proposal numbered n iff it has not responded to a prepare request having a number greater than n.
2.2.2 Proposal 與Acceptor之間的交互流程
- 階段一：
Proposer節點接收到客戶端請求，向集群中其他Acceptor節點發送該請求提案，並賦給該提案一個最新的序列號，即發送Prepare消息。
sequenceDiagram
Proposer ->> Acceptors: Prepare(n)
- 階段二：
Acceptor節點接收到Prepare消息之后需要進行檢查，如果n的值大於當前該節點之前Prepare的最大的序列號則接受該消息，並在接下來的處理過程中不再接收序列號小於n的其他Prepare消息。
sequenceDiagram
Acceptors ->> Proposer: OK, not accept Prepare.num < n and highest-numbered proposal it has accepted(if any)
- 階段三：
Proposer節點在階段一之后等待Acceptor節點的返回，當接收到大於Quorum數量的相應之后，向Acceptor節點發送Accept(n,v)消息。n即Prepare中的序列號，v = （Acceptor返回的其最大的accepted 的序列號）|| （Acceptor沒返回的情況下，Proposer節點任意指定）
sequenceDiagram
Proposer ->> Acceptors: Accept(n, v)
- 階段四：
Acceptors收到Accept之后進行請求的具體執行
3.Paxos有哪些適用領域以及其有哪些限制？
Paxos解決的問題：
- 異步網絡環境中，多進程之間操作的一致性
Paxos的前置條件有：
- 該算法只能夠適用於系統中不包含拜占庭節點的情況；
- 該算法的正確性前提是系統中不能超過一半的機器出現問題；
4.Paxos的成熟應用以及發展現狀？
Paxos目前廣泛運用在目前的分布式系統，典型的分布式協調服務有開源的Zookeeper系統以及Google的Chubby，國內的阿里的OceanBase等等。
5.分布式一致性還有哪些算法可以用？分別有哪些有缺點？
比較著名的還有VR,Raft
以及能夠容忍拜占庭節點的PBFT等