分佈式一致性算法，你肯定不瞭解一下？

 

• 集中式與分佈式
  • 集中式
  • 分佈式
  • 分佈式事務
• 一致性協議
  • 2PC：Two-Phase Commit二階段提交協議
  • 3PC:Three-phase Commit 三階段提交協議
  • Paxos算法
  • RAFT算法
• 總結

 

集中式與分佈式

集中式

就是將全部的業務都部署在一箇中心主機（節點）上，全部的功能都由這個主機集中處理。

特色

部署結構簡單、不須要考慮多個主機之間的分佈式協做問題。

分佈式

分佈式系統：指將硬件或者軟件組件部署在不一樣的網絡計算機上，彼此之間僅僅經過消息傳遞進行通訊和協調的系統。

特色

1. 分佈性：多臺計算機可空間上隨意分佈，跨機房、跨城市均可以。
2. 對等性：分佈式系統中沒有主/從之分，都是對等的節點或者服務。
   • 副本：指分佈式系統對數據或服務冗餘，以此提供高可用。
   • 數據副本：是指在不一樣的節點上持久化一份數據，當某一個節點上存儲的數據丟失時，能夠從副本上讀取到該數據，這是分佈式系統數據丟失問題最爲有效的手段。
   • 服務副本：指多個節點提供一樣的服務，每一個節點都有能力接收來自外部的請求並進行相應的處理。
3. **併發性：**分佈式系統中的多個節點，可能會併發地操做一些共享資源，諸如數據庫或分佈式存儲等。
4. **缺少全局時鐘：**一個典型的分佈式系統是由一系列在空間上隨意分佈的進程組成，進程彼此之間經過消息進行通訊。所以，沒法判斷兩個事件誰先誰後。可以使用邏輯時鐘。
5. **故障老是會發生：**除非需求指標容許，在系統設計時不能放過任何異常狀況。如宕機、網絡分區、網絡超時等。

每一次分佈式系統的請求與響應三態：成功，失敗，超時。

超時狀況：

1. 沒有成功發送到接收方，在發送過程當中發生信息丟失。
2. 成功發送到接收方，併成功處理，但返回給發送方過程當中發生信息丟失。

因此須要有冪等。

分佈式事務

分佈式事務是指事務的參與者，支持事務的服務器，資源服務器以及事務管理器分別位於分佈式系統的**不一樣節點之上。**一般一個分佈式事務中會涉及對多個數據源或業務系統的操做。分佈式事務也能夠被定義爲一種嵌套型的事務，同時也就具備了ACID事務的特性。

CAP理論

• Consistency(一致性)：數據一致更新，全部數據變更都是同步的（強一致性）。

• Availability(可用性)：好的響應性能

• Partition tolerance(分區容錯性) ：可靠性

分區容錯性：分佈式系統在遇到任何網絡分區故障的時候，任然須要保證對外提供知足一致性和可用性的服務，除非是整個網絡環境都發生了故障。

網絡分區：是指在分佈式系統中，不一樣的節點分佈在不一樣的子網絡（機房或異地網絡等）中，因爲一些特殊的緣由致使這些子網絡之間出現網絡不連通的情況，但各個子網絡的內部網絡是正常的，從而致使整個網絡的環境被切成了若干個孤立的區域。

定理：任何分佈式系統只可同時知足二點，無法三者兼顧。

須要根據實際業務進行取捨。

• CA系統（放棄P）：指將全部數據（或者僅僅是那些與事務相關的數據）都放在一個分佈式節點上，就不會存在網絡分區。因此強一致性以及可用性獲得知足。
• CP系統（放棄A）：若是要求數據在各個服務器上是強一致的，然而網絡分區會致使同步時間無限延長，那麼如此一來可用性就得不到保障了。堅持事務ACID（原子性、一致性、隔離性和持久性）的傳統數據庫以及對結果一致性很是敏感的應用一般會作出這樣的選擇。
• AP系統（放棄C）：這裏所說的放棄一致性，並非徹底放棄數據一致性，而**是放棄數據的強一致性，而保留數據的最終一致性。**若是即要求系統高可用又要求分區容錯，那麼就要放棄一致性了。由於一旦發生網絡分區，節點之間將沒法通訊，爲何知足高可用，每一個節點只能用本地數據提供服務，這樣就會致使數據不一致。一些遵照BASE原則數據庫，（如：Cassandra、CouchDB等）每每會放寬對一致性的要求（知足最終一致性便可），一次來獲取基本的可用性。

BASE理論

• Basically Available基本可用：指分佈式系統在出現不可預知的故障的時候，容許損失部分可用性——但不是系統不可用。
  • 響應時間上的損失：假如正常一個在線搜索0.5秒以內返回，但因爲故障（機房斷電或網絡不通），查詢結果的響應時間增長到1—2秒。
  • 功能上的損失：若是流量激增或者一個請求須要多個服務間配合，而此時有的服務發生了故障，這時須要進行服務降級，進而保護系統穩定性。
• Soft state軟狀態：容許系統在不一樣節點的數據副本之間進行數據同步的過程存在延遲。
• Eventually consistent最終一致：最終數據是一致的就能夠了，而不是時時高一致。

BASE思想主要強調基本的可用性，若是你須要High 可用性，也就是純粹的高性能，那麼就要以一致性或容錯性爲犧牲。

一致性協議

一致性協議：爲了使基於分佈式系統架構下的全部節點進行事務處理過程當中可以保持原子性和一致性而設計的一種算法。一般有二階段提交協議、三階段提交協議、Paxos、Zookeeper的ZAB協議、Raft、Pbft等。

2PC、3PC引入了兩個概念。

**協調者：**負責統一調度分佈式節點的執行邏輯

參與者：被調度的分佈式節點

2PC：Two-Phase Commit二階段提交協議

二階段主要採起：先嚐試，後提交。

2PC優缺點

• 二階段優勢：原理簡單，實現方便；解決分佈式事務的原子性，要麼所有執行成功，要麼所有執行失敗
• 二階段缺點：
  1. 同步阻塞：在提交執行過程當中，各個參與者都在等待其餘參與者響應的過程當中，將沒法執行其餘操做。
  2. 單點問題：只有一個協調者，協調者掛掉，整個二階段提交流程沒法執行；更爲嚴重是，在階段二時，協調者出現問題，那參與者將會一直處於鎖定事務狀態中，沒法繼續完成事務操做。
  3. 數據不一致：在階段二，協調者發送了Commit請求後，發生了網絡故障，致使只有部分參與者收到commit請求，並執行提交操做，就致使數據不一致問題。
  4. 太過保守：階段一中，若參與者出現故障，協調者沒法收到參與者的詢問反饋，只能經過自身超時機制來中斷事務。這樣的策略顯得過於保守。

3PC:Three-phase Commit 三階段提交協議

由於2PC有不少問題，因此在2PC基礎上，改進爲3PC：canCommit、preCommit、doCommit三個階段。

改進點：

1. 3PC是將2PC的第一階段分爲兩個階段，先發起事務詢問，再執行事務。
2. 同時在協調者、參與者中引入超時機制。

3PC-第一階段 3PC-事務中斷1 3PC-第三階段 3PC-事務中斷2

3PC優缺點

• 三階段優勢：

  • 下降了二階段的同步阻塞範圍（在第二階段，只要參與者收到preCommit請求，就會執行事務，此後，無論能不能收到協調者的doCommit請求,都會執行事務提交，不會出現阻塞問題）
  • 解決單點問題：進入階段三會出現兩種狀況： 1：協調者出現問題； 2：協調者與參與者之間出現網絡故障；
    • 都致使參與者沒法收到doCommit請求，但參與者在超時以後都會提交事務

• 三階段缺點：

  • 數據不一致：參與者收到preCommit請求，此時若是出現網絡分區，協調者與參與者之間沒法進行正常網絡通訊，參與者在超時以後仍是會進行事務提交，就會出現數據不一致。

因此2PC、3PC各有優缺點，可根據實際業務場景進行選擇。既然2PC、3PC都會產生數據不一致。下面咱們來看一看分佈式領域經常使用的一致性算法。

Paxos算法

Paxos算法是萊斯利·蘭伯特(Leslie Lamport)1990年提出的基於消息傳遞且具備高度容錯特性的一致性算法，是目前公認的解決分佈式一致性問題最有效的算法之一。 Paxos算法解決的問題是一個分佈式系統如何就某個值（決議）達成一致。

Paxos以及下面的RAFT都假設不存在拜占庭將軍問題，只考慮節點宕機、網絡分區、消息不可靠等問題。屬於CFT（Crash Fault Tolerance）算法。

系統中有三種角色proposers，acceptors，和 learners。能夠一個節點多個角色。

1. proposers 提出提案，提案信息包括提案編號和提議的 value；
2. acceptor 收到提案後能夠接受（accept）提案，若提案得到多數派（majority）的 acceptors 的接受，則稱該提案被批准（chosen）；
3. learners 只能「學習」被批准的提案。

多數派：指 n / 2 +1 。n爲總節點數量。

Paxos算法分爲兩個階段。具體以下：

• 階段一：

  • Proposer選擇一個提案編號N，而後向半數以上的Acceptor發送編號爲N的Prepare請求。

  • 若是一個Acceptor收到一個編號爲N的Prepare請求，且N大於該Acceptor已經響應過的全部Prepare請求的編號，那麼它就會將它已經接受過的編號最大的提案（若是有的話）做爲響應反饋給Proposer，同時該Acceptor承諾再也不接受任何編號小於N的提案。

    例如：一個acceptor已經響應過的全部prepare請求對應的提案編號分別爲一、二、。。。。5和7，那麼該acceptor在接收到一個編號爲8的prepare請求後，就會將編號爲7的提案做爲響應反饋給Proposer。

• 階段二

  • 若是Proposer收到半數以上Acceptor對其發出的編號爲N的Prepare請求的響應，那麼它就會發送一個針對**[N,V]提案的Accept請求給半數以上的Acceptor。注意：V就是階段一收到的響應中編號最大的提案的value**，若是響應中不包含任何提案，那麼V就由Proposer本身決定（任意值）。
  • 若是Acceptor收到一個針對編號爲N的提案的Accept請求，只要該Acceptor沒有對編號大於N的Prepare請求作出過響應，它就接受該提案。

注意：Proposer能夠隨時丟棄提案，而且提出新的提案；Acceptor也能夠隨時響應，接受編號更大的提案。

思考：若是兩個Proposer還處於第一階段時，互相提出編號更大的提案？會發生什麼？

這時候會出現「活鎖」狀態，陷入了無限死循環中（破壞了算法活性）。

那須要怎麼防止呢？

能夠選出一個主Proposer，只有主Proposer能夠提出提案。

至於怎麼選擇，不屬於Paxos的範疇，能夠參考RAFT使用競選，誰快誰當選；也能夠參考PBFT的依次成爲leader等。

RAFT算法

RAFT算法分爲兩個階段：Leader選舉，日誌複製。也有三種角色，分別爲：

1. Leader（領導者）：負責發送要進行共識的數據，若是客戶端發送的數據不是發送到Leader而是其餘角色，其餘角色會進行轉發至Leader。
2. Follower（追隨者）：參與共識的角色
3. Candidate（候選者）：若是Follower沒有收到Leader的心跳響應超過150——300ms，會進行Leader選舉。

每一個節點的身份均可以是以上三種中的其一。

• Leader選舉階段：

  • 全部節點初始狀態爲Follower狀態，此時沒有Leader，確定會與Leader的心跳超時（通常150——300ms，隨機的，這樣就是想誰先發出競選，誰當選leader），此時Candidate就會發出leader競選給其餘節點（你們快選我啊，leader掛掉了）；其餘節點收到競選請求，會響應贊成，當一個Candidate收到大多數（n/2 + 1）節點的回覆，就成爲leader。而後與Candidate保持心跳鏈接。Raft有個Term（任期）的概念，只有在發生Leader選舉階段，term+1，表示新的leader產生，掛掉的節點，或者掛掉的leader重啓後，會發現本身的term小於最新的，此時就會切換到日誌複製，去同步以前丟失的消息。
  • 若是同時有多個Candidate發出競選，而且都沒有得到大多數投票，會一直進行競選，直到選出leader

• 日誌複製（是一個2PC提交）

  • leader收到客戶端或者其餘節點轉發過來須要共識的值，會跟隨心跳一塊兒廣播給其餘節點，進行寫入
  • 其餘節點寫入後響應成功給leader，當leader收到大多數的follower響應的成功，發出commit命令
  • 其餘節點收到commit後，進行事務提交，響應成功爲leader，leader收到大多數的commit成功，Raft完成。

  若是leader沒有掛掉，或者發生網絡分區，就會一直是這個leader進行事務發起。

我這裏只是對於算法正常流程的描述，強烈推薦動畫版RAFT（看不懂算我輸，不過記得回來點個贊，哈哈哈）

總結

本文從集中式到分佈式理論CAP、BASE以及2PC、3PC流程，描述了分佈式事務經常使用的思想；再詳細說明了Paxos以及Raft算法流程等。Paxos以及Raft算法屬於CFT算法範疇，都能容忍最多n/2（向下取整）的節點出現宕機、網絡分區等的強一致性算法。Paxos屬於比較晦澀的算法，工程實現比較複雜，但其思想頗有借鑑意義。有興趣的能夠去看看Paxos的推導過程，我的認爲頗有意思，可以想明白每一步，對於理解其餘算法，也大有幫助；也能夠去看看Zookeerper的ZAB算法，後面有機會專門寫一篇。但這些算法不能真正意義上用於區塊鏈共識，畢竟leader說什麼，其餘節點就會執行，沒有節點之間的共識過程。那什麼算法能夠用於區塊鏈共識呢？

參考書籍：

《從Paxos到Zookeeper++分佈式一致性原理與實踐++》

參考連接：

PAXOS算法

RAFT動畫版

本文使用 mdnice 排版