文章目錄

• 拜占庭將軍問題
• Paxos
• • 問題描述
  • 執(zhí)行過程
  • • Prepare階段
    • Accept階段
    • Learner獲取提案
  • 活鎖問題
• Raft
• • 狀態(tài)機
  • 執(zhí)行流程
  • • 主節(jié)點選舉
    • 數(shù)據(jù)同步

---

拜占庭將軍問題

拜占庭位于如今的土耳其的伊斯坦布爾，是東羅馬帝國的首都。由于當時拜占庭羅馬帝國國土遼闊，為了達到防御目的，每個軍隊都分隔很遠，將軍與將軍之間只能靠信差傳消息。在戰(zhàn)爭的時候，拜占庭軍隊內(nèi)所有將軍和副官必須達成一致的共識，決定是否有贏的機會才去攻打敵人的陣營。但是，在軍隊內(nèi)有可能存有叛徒和敵軍的間諜，叛徒可以任意行動以達到以下目標：欺騙某些將軍采取進攻行動；促成一個不是所有將軍都同意的決定，如當將軍們不希望進攻時促成進攻行動；或者迷惑某些將軍，使他們無法做出決定。如果叛徒達到了這些目的之一，則任何攻擊行動的結果都是注定要失敗的，只有完全達成一致的努力才能獲得勝利。

這時候，在已知有成員謀反的情況下，其余忠誠的將軍在不受叛徒的影響下如何達成一致的協(xié)議，拜占庭問題就此形成 。

拜占庭將軍問題的核心在于在缺少可信任的中央節(jié)點和可信任的通道的情況下，分布在不同地方的各個節(jié)點應如何達成共識。我們可以將這個問題延伸到分布式計算領域中。

在分布式計算領域中，試圖在異步系統(tǒng)和不可靠的通道上達到一致性狀態(tài)是不可能的，因此在對一致性的研究過程中，都往往假設信道是可靠的，而事實上，大多數(shù)系統(tǒng)都是部署在同一個局域網(wǎng)中，因此消息被篡改的情況非常罕見；另一方面，由于機器硬件和網(wǎng)絡原因?qū)е碌南⒉煌暾麊栴}，也僅僅只需要一套簡單的校驗算法即可避免。

那么當我們假設拜占庭問題不存在（所有消息都是完整的，沒有被篡改），那么這種情況下需要什么算法來保證一致性呢？拜占庭將軍問題的提出者Lamport提出了一種非拜占庭將軍問題的一致性解決方案——Paxos算法

---

Paxos

問題描述

與拜占庭將軍問題一樣，Lamport同樣使用故事的方式來提出Paxos問題

希臘島嶼Paxon上的議員在議會大廳中表決通過法律，并通過服務員傳遞紙條的方式交流信息，每個議員會將通過的法律記錄在自己的賬目上。問題在于執(zhí)法者和服務員都不可靠，他們隨時會因為各種事情離開議會大廳，并隨時可能有新的議員進入議會大廳進行法律表決，使用何種方式能夠使得這個表決過程正常進行，且通過的法律不發(fā)生矛盾。

不難看出故事中的議會大廳就是分布式系統(tǒng)，議員對應節(jié)點或進程，服務員傳遞紙條的過程就是消息傳遞的過程，法律即是我們需要保證一致性的值。議員和服務員的進出對應著節(jié)點/網(wǎng)絡的失效和加入，議員的賬目對應節(jié)點中的持久化存儲設備。上面表決過程的正常進行可以表述為進展需求：當大部分議員在議會大廳呆了足夠長時間，且期間沒有議員進入或者退出，那么提出的法案應該被通過并被記錄在每個議員的賬目上。

Paxos算法需要解決的問題就是如何在上述分布式系統(tǒng)中，快速且正確地在集群內(nèi)部對某個數(shù)據(jù)的值達成一致，并且保證不論發(fā)生以上任何異常，都不會破壞整個系統(tǒng)的一致性。

Paxos解決的問題

為了能夠使得表決過程正常進行，且通過的法律不發(fā)生矛盾，那么我們需要保證以下幾點

• 在這些被提出的提案中，最后只能有一個被選定
• 如果沒有提案被提出，那么就不會有被選定的提案
• 當一個提案被選定后，節(jié)點們應該可以獲取被選定的提案信息

在Paxos算法中，主要有以下三種角色，并且一個節(jié)點可能同時擔任幾種角色

• 提議者（Proposer）：負責提出提議；
• 接受者（Acceptor）：對每個提議進行投票；
• 告知者（Learner）：被告知投票的結果，不參與投票過程。

各節(jié)點之間的關系

同時，假設不同參與者之間通過收發(fā)消息來進行通信，那么我們需要具備以下條件

• 每個參與者可能會因為出錯而導致停止、重啟等情況，
• 雖然消息在傳輸過程中可能會出現(xiàn)不可預知的延遲、重復、丟失等情況，但是消息不會被損壞或篡改（即不存在拜占庭問題）

執(zhí)行過程

首先我們規(guī)定一個提議包含兩個字段：[n, v]，其中 n 為序號（具有唯一性），v 為提議值。

Paxos執(zhí)行過程主要分為兩個階段，與之前講過的2PC（二階段提交協(xié)議）類似。

• Prepare階段
• Accept階段

如下圖

Paxos算法流程

Prepare階段

1. 首先，每個Proposer都會向所有的Acceptor發(fā)送一個Prepare請求。
2. 當Acceptor接收到一個Prepare請求，提議內(nèi)容為[n1,v1]，由于之前還未接受過Prepare請求，那么它會返回一個[no previous]的Prepare響應，并且設置當前接受的提議為[n1,v1]，同時保證以后不會再接收序號小于n1的提議。
3. 如果Acceptor再次收到一個Prepare請求，提議內(nèi)容為[n2,v2]，此時會有兩種情況。
   • 如果n2 < n1，此時Acceptor就會直接拋棄該請求
   • 如果n2 >= n1，此時Acceptor就會發(fā)送一個[n1,v1]的Prepare響應，設置當前接受到的提議為[n2,v2]，同時保證與上一步邏輯相同，保證以后不會再接受序號小于n2的提議。

Accept階段

1. 當一個Proposer接收到超過一半的Acceptor的Prepare響應時，此時它就會發(fā)送一個針對[n,v]提案的Accept請求給Acceptor。
2. 如果一個Acceptor收到一個編號為n的提案的Accept請求，此時有兩種情況。
   • 如果該Acceptor沒有對編號大于n的Prepare請求做出過響應，它就會接受該提案，并發(fā)送Learn提議給Learner
   • 如果該Acceptor接受過編號大于n的Prepare請求，那么它就會拒絕、不回應或回復error。（如果一個Proposer沒有收到過半的回應，那他就會重新進入第一階段，遞增提案號后重新提出Prepare請求）

在上述過程中，每一個Proposer都有可能會產(chǎn)生多個提案。但只要每個Proposer都遵循如上述算法運行，就一定能保證算法執(zhí)行的正確性。

Learner獲取提案

在Accept階段之后Acceptor選定提案后，根據(jù)具體的應用場景不同，Learner主要采用以下三種方案來學習選定的提案

方案	優(yōu)點	缺點
Acceptor直接將提議發(fā)給所有的Learner	Learner能夠快速獲取被選定的提議	通信次數(shù)過多，每個Acceptor都要和Learn產(chǎn)生通信（M * N）
Acceptor接受提議后將提議發(fā)給主Learner，主Learner再通知其他Learner	通信次數(shù)減少（M + N - 1）	單點問題（主Learner出現(xiàn)故障就會崩潰）
Acceptor將提議發(fā)一個Learner集合，Learener集合再發(fā)給其他Learener	解決了單點問題，集合中Learner個數(shù)越多就越可靠	網(wǎng)絡通信復雜度變高

當Learner們發(fā)現(xiàn)有大多數(shù)的Acceptor接受了某一個提議，那么該提議的提議值則就是Paxos最終選擇出來的結果。

活鎖問題

在Paxos算法實際運作的時候還存在這樣一種極端的情況——當有兩個Proposer依次提出了一系列編號遞增的提案，此時就會導致陷入死循環(huán)，無法完成第二階段，也就是無法選定一個提案，如以下場景。

1. Proposer P1發(fā)出編號為n1的Prepare請求，收到過半響應，完成了階段一的流程。
2. 同時，Proposer P2發(fā)出編號為n2的Prepare請求（n2 > n1），也收到了過半的響應，完成了階段一的流程，并且Acceptor承諾不再接受編號小于n2的提案。
3. P1進入第二階段時，由于Acceptor不接受小于n2的提案，所以P1重新回到第一階段，遞增提案號為n3后重新發(fā)出Prepare請求
4. 緊接著，P2進入第二階段，由于Acceptor不接受小于n3的提案，此時它也重新回到第一階段，遞增提案號后重新發(fā)出Prepare請求
5. 于是P1、P2陷入了死循環(huán)，誰都無法完成階段二，這也就導致了沒有value能被選定。

為了保證Paxos算法的可持續(xù)性，以避免陷入上述提到的死循環(huán)，就必須選擇一個主Proposer，并規(guī)定只有主Proposer才能夠提出提案。這樣一來，只要主Proposer和過半的Acceptor能夠正常進行網(wǎng)絡通信，那么肯定會有一個提案被批準（第二階段的accept），則可以解決死循環(huán)導致的活鎖問題。

---

Raft

從上面可以看出，Paxos算法相對來說較為復雜且難以理解，因此在后來又出現(xiàn)了一種用于替代Paxos的算法——Raft

Raft算法是一種簡單易懂的共識算法，所謂共識，就是多個節(jié)點對某個事情達成一致的看法，即使是在部分節(jié)點故障、網(wǎng)絡延時、網(wǎng)絡分割的情況下。它依靠狀態(tài)機和主從同步的方式，在各個節(jié)點之間實現(xiàn)數(shù)據(jù)的一致性。

Raft算法的核心主要為以下兩部分，下面將進行具體講解

• 主節(jié)點選舉（Leader Election）
• 數(shù)據(jù)同步（Log Replication）

狀態(tài)機

在Raft中節(jié)點中存在三種狀態(tài)，狀態(tài)之間可以相互進行轉(zhuǎn)換

• Leader（主節(jié)點）

• Follower（從節(jié)點）

• Candidate（競選節(jié)點）

同時，每個節(jié)點上會存放一個倒計時器（Election Timeout），時間隨機在150ms到300ms之間。Leader節(jié)點會周期性的向所有Follower發(fā)送一個心跳包（Heartbeat），收到心跳包的節(jié)點會將其計時器清零后重新計時，如果在倒計時結束前沒有收到Leader的心跳包，此時Follower就會變?yōu)镃andidate，開始進入競選狀態(tài)。

具體的狀態(tài)轉(zhuǎn)移如下圖

狀態(tài)轉(zhuǎn)換圖

執(zhí)行流程

主節(jié)點選舉

介紹了狀態(tài)機后，下面就來看看主節(jié)點的選舉流程

第一步，在一開始時，由于沒有Leader，所以此時所有節(jié)點的身份都是Follower，每一個節(jié)點上都有著自己的計數(shù)器，當計時器達到了超時時間后，該節(jié)點就會轉(zhuǎn)換為Candidate，開始選舉過程。

第一步：開始選舉

第二步，成為Candidate的節(jié)點首先會給自己投一張票，然后向集群中的其他所有節(jié)點發(fā)起投票請求。

第二步：開始拉票

第三步，收到投票請求并且還未投票的Follower節(jié)點會向發(fā)起者回復投票反饋，如果收到了超過半數(shù)的回復，此時Candidate選舉成功，狀態(tài)轉(zhuǎn)變?yōu)長eader。

第三步：選舉成功

第四步，Leader節(jié)點會立刻向其他節(jié)點發(fā)出通告，告知其他節(jié)點它已成功選舉成Leader，收到通知的節(jié)點會轉(zhuǎn)換為Follower。并且Leader會周期性的發(fā)送心跳包給所有Follower來表明它還存活，當Follower接收到心跳包時，就會重置計時器。

第四步：Leader向其他節(jié)點發(fā)送通知

一旦Leader節(jié)點掛掉，它就無法發(fā)出心跳包來重置Follower的倒計時器，那么當Follower的超時時間到達后，其就會轉(zhuǎn)換成Candidate節(jié)點，再次重復以上過程。

上面介紹的是單節(jié)點的選舉，倘若同時有多個Follower同時倒計時結束后成為Candidate，同時開始選舉，并且在選舉過程中所獲得的票數(shù)相同，此時就陷入了僵局，誰都無法成為Leader。

多個Candidate選舉時出現(xiàn)僵局

在重新選舉時，由于每個節(jié)點設置的超時時間都是隨機的，因此下一次同時出現(xiàn)多個Candidate并獲得同樣票數(shù)導致選舉失敗的情況的概率則非常低。

隨機化超時時間避免沖突

數(shù)據(jù)同步

Raft中數(shù)據(jù)同步的方式與之前寫過的2PC（二階段提交協(xié)議）有一些相似，也是分為投票和提交兩個階段，具體流程如下。

第一步，客戶端將修改傳入Leader中（此時修改并沒有提交，只是寫入日志中）。

客戶端將修改傳入Leader

第二步，Leader將修改復制到集群內(nèi)的所有Follower節(jié)點上，如果復制失敗，會不斷進行重試直至成功。

Leader將修改復制到所有Follower

第三步，Follow節(jié)點們成功接收到復制的數(shù)據(jù)后，會反饋結果給Leader節(jié)點，如果Leader節(jié)點接收到超過半數(shù)的Follower反饋，則表明復制成功，于是提交自己的數(shù)據(jù)，并且通知客戶端數(shù)據(jù)提交成功。

Follower接受成功后反饋結果

第四步，提交成功后，Leader會通知所有的Follower讓它們也提交修改，此時所有節(jié)點的值達成一致，完成數(shù)據(jù)同步流程。

Leader通知所有節(jié)點提交，完成數(shù)據(jù)同步

為了便于理解，可以結合下面的Raft原理動畫一同學習。

Raft原理動畫

除了上面介紹的Paxos、Raft，還有其他的一些解決分布式一致性的共識算法，如Zookeeper使用的ZAB，區(qū)塊鏈中使用的PBFT等，在未來的博客中，如果有機會我還會繼續(xù)為大家分享這些內(nèi)容。

總結

以上是生活随笔為你收集整理的分布式系统概念 | 一致性协议：拜占庭将军问题、Paxos、Raft的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。