Paxos&Raft算法介紹

Paoxs算法介紹

Paxos算法是萊斯利·蘭伯特於1989年提出的一種基於消息傳遞模型的一致性算法，是目前公認的解決分布式一致性問題最有效的算法之一。

在一個分布式系統中，數據往往以多副本的形式存儲在不同節點上，如分布式數據庫系統，用戶對系統的更新請求會同時發送給各個節點。但實際上系統是不可靠的，如節點可能會宕機、消息處理可能會慢、程序可能出故障，網絡可能會延遲、中斷等。如何在上述系統中保證在任何異常情況下，都不會破壞各個節點的數據一致性，正是Paxos要解決的問題。

1.   背景

傳統的主從同步無法同時保證數據的一致性和可用性，分布式系統中著名的CAP理論從理論上證明了這個問題。CAP理論告訴我們C、A、P三者不能同時滿足，最多只能滿足其中兩個。

一般來說使用網絡通信的分布式系統，無法舍棄P性質，那么就只能在一致性和可用性上做一個艱難的選擇。既然在分布式系統中一致性和可用性只能選一個。那Paxos、Raft等分布式一致性算法是如何做到在保證一定的可用性的同時，對外提供強一致性呢。

 

1. 首先，由於分區很少發生，那么在系統不存在分區的情況下沒什么理由犧牲C或A；
2. 其次，C與A之間的取舍可以在同一系統內以非常細小的粒度反復發生，而每一次的決策可能因為具體的操作，乃至因為牽涉到特定的數據或用戶而有所不同；
3. 最后，這三種性質都可以在程度上衡量，並不是非黑即白的有或無。可用性可以在0%到100%之間連續變化的，一致性分很多級別，連分區也可以細分為不同含義，如系統內的不同部分對於是否存在分區可以有不一樣的認知。

 

所以一致性和可用性並不是水火不容，非此即彼的。Paxos、Raft等分布式一致性算法就在一致性和可用性之間做到了很好的平衡。

2.   算法原理

Paxos算法運行在允許宕機故障的異步系統中，不要求可靠的消息傳遞，可容忍消息丟失、延遲、亂序以及重復。它利用大多數 (Majority) 機制保證了2F+1的容錯能力，即2F+1個節點的系統最多允許F個節點同時出現故障。

Paxos將系統中的角色分為提議者 (Proposer)，決策者 (Acceptor)，和最終決策學習者 (Learner):

Proposer: 提出提案 (Proposal)。Proposal信息包括提案編號 (Proposal ID) 和提議的值 (Value)。

Acceptor：參與決策，回應Proposers的提案。收到Proposal后可以接受提案，若Proposal獲得多數Acceptors的接受，則稱該Proposal被批准。

Learner：不參與決策，從Proposers/Acceptors學習最新達成一致的提案（Value）。

 

一個或多個提議進程 (Proposer) 可以發起提案 (Proposal)，Paxos算法使所有提案中的某一個提案，在所有進程中達成一致。系統中的多數派同時認可該提案，即達成了一致。最多只針對一個確定的提案達成一致。在多副本狀態機中，每個副本可以在Proposer、Acceptor、Learner三種角色中轉換。

 

Paxos算法通過一個決議分為兩個階段（Learn階段之前決議已經形成）：

1. 第一階段：Prepare階段。Proposer向Acceptors發出Prepare請求，Acceptors針對收到的Prepare請求進行Promise承諾。
2. 第二階段：Accept階段。Proposer收到超過半數Acceptors承諾的Promise后，向Acceptors發出Propose請求。Acceptors針對收到的Propose請求進行Accept處理。
3. 第三階段：Learn階段。Proposer在收到多數Acceptors的Accept之后，標志着本次Accept成功，決議形成，將形成的決議發送給所有Learners。

Paxos算法偽代碼描述如下：

 

1. 獲取一個Proposal ID n，為了保證Proposal ID唯一，可采用時間戳+Server ID生成；
2. Proposer向所有Acceptors廣播Prepare(n)請求；
3. Acceptor比較n和minProposal，如果n>minProposal，minProposal=n，並且將 acceptedProposal 和 acceptedValue 返回；
4. Proposer接收到過半數回復后，如果發現有acceptedValue返回，將所有回復中acceptedProposal最大的acceptedValue作為本次提案的value，否則可以任意決定本次提案的value；
5. 到這里可以進入第二階段，廣播Accept (n,value) 到所有節點；
6. Acceptor比較n和minProposal，如果n>=minProposal，則acceptedProposal=minProposal=n，acceptedValue=value，本地持久化后，返回；否則，返回minProposal。
7. 提議者接收到過半數請求后，如果發現有返回值result >n，表示有更新的提議，跳轉到1；否則value達成一致。

第一階段是為了獲取集群中存儲的最新的那條數據，第二階段是為了將這條最新的數據同步到所有節點。在集群數據達成一致后，Proposer再次廣播與上次相同的Prepare(n)請求時，由於n已經和Acceptor中保存的minProposal相等，Acceptor將不會返回acceptedProposal 和 acceptedValue，此時若用戶希望執行更新操作，Proposer即可將用戶需要更新的值設為本次提案的value，從而在第二階段將value同步給所有節點。

當集群中存在多個Proposer，且提出了不同提案value時，因為消息到達順序的不可控，有可能a節點先收到了Proposer1的提案value1，b節點先收到了Proposer2的提案value2，假設Proposer1的Proposer ID大於Proposer2的Proposer ID，則當a節點收到Proposer2的提案時，由於minProposal>n，將直接返回minProposal。此時Proposer2收到a節點的返回發現result >n，將重新進入階段一，進行集群同步。

 

 

引用

[1] https://zhuanlan.zhihu.com/p/31727291

[2] https://zhuanlan.zhihu.com/p/31780743

 

 

Raft算法介紹

參見

https://zhuanlan.zhihu.com/p/32052223

https://www.infoq.cn/article/raft-paper

 

 

Paxos&Raft算法比較

 

raft是paxos算法的一種改進，一種簡化，一種優化，一種具象化。Raft容易實現在於它的描述是非常規范的，包括了所有的實現細節。如上面的人說的有如偽代碼。

paxos的描述側重於理論，工程實現按照谷歌chubby論文中的說話，大家從paxos出現，寫着寫着，處理了n多實際中的細節之后，已經變成另外一個算法了，這時候正確性已經無法得到理論的保證。

 

但是 Raft 協議做了一個約束，數據庫的多個投票多條日志一定要按照順序執行，只有前一個日志被確認了才能再確認后一個日志。導致了兩個問題，第一個問題是並發能力變差了。以前支持並發的提交，現在只能支持一個結束以后再進入下一個，所以它的性能變差了。第二個是可用性的問題。如果采用 Paxos 協議，當一台機器新上線的時候很快就能提供服務，因為不需要等前面的數據確認就能提供服務，但是如果使用的是 Raft 協議，需要等前面的所有日志確認以后才能提供服務，所以說 Raft 協議存在可用性的風險。

 

引用

[1] https://www.zhihu.com/question/36648084

[2] https://www.oceanbase.com/blog/fzbqhi

[3] https://www.oceanbase.com/blog/mqlia7