關於分佈式，你須要知道的真相

目錄

• 1、分佈式鎖
• 數據庫的惟一索引
• Redis 的 SETNX 指令
• Redis 的 RedLock 算法
• Zookeeper 的有序節點
• 2、分佈式事務
• 2PC
• 本地消息表
• 3、CAP
• 一致性
• 可用性
• 分區容忍性
• 權衡
• 4、BASE
• 基本可用
• 軟狀態
• 最終一致性
• 5、Paxos
• 執行過程
• 約束條件
• 6、Raft
• 單個 Candidate 的競選
• 多個 Candidate 競選
• 數據同步

1、分佈式鎖

在單機場景下，可使用語言的內置鎖來實現進程同步。可是在分佈式場景下，須要同步的進程可能位於不一樣的節點上，那麼就須要使用分佈式鎖。

阻塞鎖一般使用互斥量來實現：

• 互斥量爲 0 表示有其它進程在使用鎖，此時處於鎖定狀態；
• 互斥量爲 1 表示未鎖定狀態。

1 和 0 能夠用一個整型值表示，也能夠用某個數據是否存在表示。

數據庫的惟一索引

得到鎖時向表中插入一條記錄，釋放鎖時刪除這條記錄。惟一索引能夠保證該記錄只被插入一次，那麼就能夠用這個記錄是否存在來判斷是否存於鎖定狀態。

存在如下幾個問題：

• 鎖沒有失效時間，解鎖失敗的話其它進程沒法再得到該鎖。
• 只能是非阻塞鎖，插入失敗直接就報錯了，沒法重試。
• 不可重入，已經得到鎖的進程也必須從新獲取鎖。

Redis 的 SETNX 指令

使用 SETNX（set if not exist）指令插入一個鍵值對，若是 Key 已經存在，那麼會返回 False，不然插入成功並返回 True。

SETNX 指令和數據庫的惟一索引相似，保證了只存在一個 Key 的鍵值對，那麼能夠用一個 Key 的鍵值對是否存在來判斷是否存於鎖定狀態。

EXPIRE 指令能夠爲一個鍵值對設置一個過時時間，從而避免了數據庫惟一索引實現方式中釋放鎖失敗的問題。

Redis 的 RedLock 算法

使用了多個 Redis 實例來實現分佈式鎖，這是爲了保證在發生單點故障時仍然可用。

• 嘗試從 N 個互相獨立 Redis 實例獲取鎖；
• 計算獲取鎖消耗的時間，只有當這個時間小於鎖的過時時間，而且從大多數（N / 2 + 1）實例上獲取了鎖，那麼就認爲鎖獲取成功了；
• 若是鎖獲取失敗，就到每一個實例上釋放鎖。

Zookeeper 的有序節點

1. Zookeeper 抽象模型

Zookeeper 提供了一種樹形結構的命名空間，/app1/p_1 節點的父節點爲 /app1。

 

 

 

2. 節點類型

• 永久節點：不會由於會話結束或者超時而消失；
• 臨時節點：若是會話結束或者超時就會消失；
• 有序節點：會在節點名的後面加一個數字後綴，而且是有序的，例如生成的有序節點爲 /lock/node-0000000000，它的下一個有序節點則爲 /lock/node-0000000001，以此類推。

3. 監聽器

爲一個節點註冊監聽器，在節點狀態發生改變時，會給客戶端發送消息。

4. 分佈式鎖實現

• 建立一個鎖目錄 /lock；
• 當一個客戶端須要獲取鎖時，在 /lock 下建立臨時的且有序的子節點；
• 客戶端獲取 /lock 下的子節點列表，判斷本身建立的子節點是否爲當前子節點列表中序號最小的子節點，若是是則認爲得到鎖；不然監聽本身的前一個子節點，得到子節點的變動通知後重復此步驟直至得到鎖；
• 執行業務代碼，完成後，刪除對應的子節點。

5. 會話超時

若是一個已經得到鎖的會話超時了，由於建立的是臨時節點，因此該會話對應的臨時節點會被刪除，其它會話就能夠得到鎖了。能夠看到，Zookeeper 分佈式鎖不會出現數據庫的惟一索引實現的分佈式鎖釋放鎖失敗問題。

6. 羊羣效應

一個節點未得到鎖，只須要監聽本身的前一個子節點，這是由於若是監聽全部的子節點，那麼任意一個子節點狀態改變，其它全部子節點都會收到通知（羊羣效應），而咱們只但願它的後一個子節點收到通知。

2、分佈式事務

指事務的操做位於不一樣的節點上，須要保證事務的 ACID 特性。

例如在下單場景下，庫存和訂單若是不在同一個節點上，就涉及分佈式事務。

2PC

兩階段提交（Two-phase Commit，2PC），經過引入協調者（Coordinator）來協調參與者的行爲，並最終決定這些參與者是否要真正執行事務。

1. 運行過程

1.1 準備階段

協調者詢問參與者事務是否執行成功，參與者發回事務執行結果。

 

 

 

1.2 提交階段

若是事務在每一個參與者上都執行成功，事務協調者發送通知讓參與者提交事務；不然，協調者發送通知讓參與者回滾事務。

須要注意的是，在準備階段，參與者執行了事務，可是還未提交。只有在提交階段接收到協調者發來的通知後，才進行提交或者回滾。

 

 

 

2. 存在的問題

2.1 同步阻塞

全部事務參與者在等待其它參與者響應的時候都處於同步阻塞狀態，沒法進行其它操做。

2.2 單點問題

協調者在 2PC 中起到很是大的做用，發生故障將會形成很大影響。特別是在階段二發生故障，全部參與者會一直等待，沒法完成其它操做。

2.3 數據不一致

在階段二，若是協調者只發送了部分 Commit 消息，此時網絡發生異常，那麼只有部分參與者接收到 Commit 消息，也就是說只有部分參與者提交了事務，使得系統數據不一致。

2.4 太過保守

任意一個節點失敗就會致使整個事務失敗，沒有完善的容錯機制。

本地消息表

本地消息表與業務數據表處於同一個數據庫中，這樣就能利用本地事務來保證在對這兩個表的操做知足事務特性，而且使用了消息隊列來保證最終一致性。

1. 在分佈式事務操做的一方完成寫業務數據的操做以後向本地消息表發送一個消息，本地事務能保證這個消息必定會被寫入本地消息表中。
2. 以後將本地消息表中的消息轉發到消息隊列中，若是轉發成功則將消息從本地消息表中刪除，不然繼續從新轉發。
3. 在分佈式事務操做的另外一方從消息隊列中讀取一個消息，並執行消息中的操做。

 

 

 

3、CAP

分佈式系統不可能同時知足一致性（C：Consistency）、可用性（A：Availability）和分區容忍性（P：Partition Tolerance），最多隻能同時知足其中兩項。

 

 

 

一致性

一致性指的是多個數據副本是否能保持一致的特性，在一致性的條件下，系統在執行數據更新操做以後可以從一致性狀態轉移到另外一個一致性狀態。

對系統的一個數據更新成功以後，若是全部用戶都可以讀取到最新的值，該系統就被認爲具備強一致性。

可用性

可用性指分佈式系統在面對各類異常時能夠提供正常服務的能力，能夠用系統可用時間佔總時間的比值來衡量，4 個 9 的可用性表示系統 99.99% 的時間是可用的。

在可用性條件下，要求系統提供的服務一直處於可用的狀態，對於用戶的每個操做請求老是可以在有限的時間內返回結果。

分區容忍性

網絡分區指分佈式系統中的節點被劃分爲多個區域，每一個區域內部能夠通訊，可是區域之間沒法通訊。

在分區容忍性條件下，分佈式系統在遇到任何網絡分區故障的時候，仍然須要能對外提供一致性和可用性的服務，除非是整個網絡環境都發生了故障。

權衡

在分佈式系統中，分區容忍性必不可少，由於須要老是假設網絡是不可靠的。所以，CAP 理論其實是要在可用性和一致性之間作權衡。

可用性和一致性每每是衝突的，很難使它們同時知足。在多個節點之間進行數據同步時，

• 爲了保證一致性（CP），不能訪問未同步完成的節點，也就失去了部分可用性；
• 爲了保證可用性（AP），容許讀取全部節點的數據，可是數據可能不一致。

4、BASE

BASE 是基本可用（Basically Available）、軟狀態（Soft State）和最終一致性（Eventually Consistent）三個短語的縮寫。

BASE 理論是對 CAP 中一致性和可用性權衡的結果，它的核心思想是：即便沒法作到強一致性，但每一個應用均可以根據自身業務特色，採用適當的方式來使系統達到最終一致性。

基本可用

指分佈式系統在出現故障的時候，保證核心可用，容許損失部分可用性。

例如，電商在作促銷時，爲了保證購物系統的穩定性，部分消費者可能會被引導到一個降級的頁面。

軟狀態

指容許系統中的數據存在中間狀態，並認爲該中間狀態不會影響系統總體可用性，即容許系統不一樣節點的數據副本之間進行同步的過程存在時延。

最終一致性

最終一致性強調的是系統中全部的數據副本，在通過一段時間的同步後，最終能達到一致的狀態。

ACID 要求強一致性，一般運用在傳統的數據庫系統上。而 BASE 要求最終一致性，經過犧牲強一致性來達到可用性，一般運用在大型分佈式系統中。

在實際的分佈式場景中，不一樣業務單元和組件對一致性的要求是不一樣的，所以 ACID 和 BASE 每每會結合在一塊兒使用。

5、Paxos

用於達成共識性問題，即對多個節點產生的值，該算法能保證只選出惟一一個值。

主要有三類節點：

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

 

 

 

執行過程

規定一個提議包含兩個字段：[n, v]，其中 n 爲序號（具備惟一性），v 爲提議值。

1. Prepare 階段

下圖演示了兩個 Proposer 和三個 Acceptor 的系統中運行該算法的初始過程，每一個 Proposer 都會向全部 Acceptor 發送 Prepare 請求。

 

 

 

當 Acceptor 接收到一個 Prepare 請求，包含的提議爲 [n1, v1]，而且以前還未接收過 Prepare 請求，那麼發送一個 Prepare 響應，設置當前接收到的提議爲 [n1, v1]，而且保證之後不會再接受序號小於 n1 的提議。

以下圖，Acceptor X 在收到 [n=2, v=8] 的 Prepare 請求時，因爲以前沒有接收過提議，所以就發送一個 [no previous] 的 Prepare 響應，設置當前接收到的提議爲 [n=2, v=8]，而且保證之後不會再接受序號小於 2 的提議。其它的 Acceptor 相似。

 

 

 

若是 Acceptor 接收到一個 Prepare 請求，包含的提議爲 [n2, v2]，而且以前已經接收過提議 [n1, v1]。若是 n1 > n2，那麼就丟棄該提議請求；不然，發送 Prepare 響應，該 Prepare 響應包含以前已經接收過的提議 [n1, v1]，設置當前接收到的提議爲 [n2, v2]，而且保證之後不會再接受序號小於 n2 的提議。

以下圖，Acceptor Z 收到 Proposer A 發來的 [n=2, v=8] 的 Prepare 請求，因爲以前已經接收過 [n=4, v=5] 的提議，而且 n > 2，所以就拋棄該提議請求；Acceptor X 收到 Proposer B 發來的 [n=4, v=5] 的 Prepare 請求，由於以前接收到的提議爲 [n=2, v=8]，而且 2 <= 4，所以就發送 [n=2, v=8] 的 Prepare 響應，設置當前接收到的提議爲 [n=4, v=5]，而且保證之後不會再接受序號小於 4 的提議。Acceptor Y 相似。

 

 

 

2. Accept 階段

當一個 Proposer 接收到超過一半 Acceptor 的 Prepare 響應時，就能夠發送 Accept 請求。

Proposer A 接收到兩個 Prepare 響應以後，就發送 [n=2, v=8] Accept 請求。該 Accept 請求會被全部 Acceptor 丟棄，由於此時全部 Acceptor 都保證不接受序號小於 4 的提議。

Proposer B 事後也收到了兩個 Prepare 響應，所以也開始發送 Accept 請求。須要注意的是，Accept 請求的 v 須要取它收到的最大提議編號對應的 v 值，也就是 8。所以它發送 [n=4, v=8] 的 Accept 請求。

 

 

 

3. Learn 階段

Acceptor 接收到 Accept 請求時，若是序號大於等於該 Acceptor 承諾的最小序號，那麼就發送 Learn 提議給全部的 Learner。當 Learner 發現有大多數的 Acceptor 接收了某個提議，那麼該提議的提議值就被 Paxos 選擇出來。

 

 

 

約束條件

1. 正確性

指只有一個提議值會生效。

由於 Paxos 協議要求每一個生效的提議被多數 Acceptor 接收，而且 Acceptor 不會接受兩個不一樣的提議，所以能夠保證正確性。

2. 可終止性

指最後總會有一個提議生效。

Paxos 協議可以讓 Proposer 發送的提議朝着能被大多數 Acceptor 接受的那個提議靠攏，所以可以保證可終止性。

6、Raft

Raft 也是分佈式一致性協議，主要是用來競選主節點。

單個 Candidate 的競選

有三種節點：Follower、Candidate 和 Leader。Leader 會週期性的發送心跳包給 Follower。每一個 Follower 都設置了一個隨機的競選超時時間，通常爲 150ms~300ms，若是在這個時間內沒有收到 Leader 的心跳包，就會變成 Candidate，進入競選階段。

• 下圖展現一個分佈式系統的最初階段，此時只有 Follower 沒有 Leader。Node A 等待一個隨機的競選超時時間以後，沒收到 Leader 發來的心跳包，所以進入競選階段。

 

 

 

• 此時 Node A 發送投票請求給其它全部節點。

 

 

 

• 其它節點會對請求進行回覆，若是超過一半的節點回復了，那麼該 Candidate 就會變成 Leader。

 

 

 

• 以後 Leader 會週期性地發送心跳包給 Follower，Follower 接收到心跳包，會從新開始計時。

 

 

 

多個 Candidate 競選

• 若是有多個 Follower 成爲 Candidate，而且所得到票數相同，那麼就須要從新開始投票。例以下圖中 Node B 和 Node D 都得到兩票，須要從新開始投票。

 

 

 

• 因爲每一個節點設置的隨機競選超時時間不一樣，所以下一次再次出現多個 Candidate 並得到一樣票數的機率很低。

 

 

 

數據同步

• 來自客戶端的修改都會被傳入 Leader。注意該修改還未被提交，只是寫入日誌中。

 

 

 

• Leader 會把修改複製到全部 Follower。

 

 

 

• Leader 會等待大多數的 Follower 也進行了修改，而後纔將修改提交。

 

 

 

• 此時 Leader 會通知的全部 Follower 讓它們也提交修改，此時全部節點的值達成一致。