解密ZAB協議：Zookeeper一致性的核心實現

一致性問題

設計一個分布式系統必定會遇到一個問題—— 因為分區容忍性（partition tolerance）的存在，就必定要求我們需要在系統可用性（availability）和數據一致性（consistency）中做出權衡 。這就是著名的 CAP 定理。

ZooKeeper 的處理方式，保證了 CP（數據一致性）

一致性協議和算法

而為了解決數據一致性問題，在科學家和程序員的不斷探索中，就出現了很多的一致性協議和算法。比如 2PC（兩階段提交），3PC（三階段提交），Paxos 算法等等。

拜占庭將軍問題 。它意指 在不可靠信道上試圖通過消息傳遞的方式達到一致性是不可能的，所以所有的一致性算法的 必要前提 就是安全可靠的消息通道。

而為什么要去解決數據一致性的問題？想想，如果一個秒殺系統將服務拆分成了下訂單和加積分服務，這兩個服務部署在不同的機器上了，萬一在消息的傳播過程中積分系統宕機了，總不能你這邊下了訂單卻沒加積分吧？是需要保證兩邊的數據一致的

2PC（兩階段提交）

兩階段提交是一種保證分布式系統數據一致性的協議，現在很多數據庫都是采用的兩階段提交協議來完成 分布式事務 的處理。

所需要解決的是在分布式系統中，整個調用鏈中，所有服務的數據處理要么都成功要么都失敗，即所有服務的 原子性問題 。

在兩階段提交中，主要涉及到兩個角色，分別是協調者和參與者。

第一階段：當要執行一個分布式事務的時候，事務發起者首先向協調者發起事務請求，然后協調者會給所有參與者發送 prepare 請求（其中包括事務內容）告訴參與者你們需要執行事務了，如果能執行我發的事務內容那么就先執行但不提交，執行后請給我回復。然后參與者收到 prepare 消息后，他們會開始執行事務（但不提交），并將 Undo 和 Redo 信息記入事務日志中，之后參與者就向協調者反饋是否準備好了。
第二階段：第二階段主要是協調者根據參與者反饋的情況來決定接下來是否可以進行事務的提交操作，即提交事務或者回滾事務。

比如這個時候 所有的參與者 都返回了準備好了的消息，這個時候就進行事務的提交，協調者此時會給所有的參與者發送 Commit 請求 ，當參與者收到 Commit 請求的時候會執行前面執行的事務的 提交操作 ，提交完畢之后將給協調者發送提交成功的響應。

而如果在第一階段并不是所有參與者都返回了準備好了的消息，那么此時協調者將會給所有參與者發送 回滾事務的 rollback 請求，參與者收到之后將會 回滾它在第一階段所做的事務處理 ，然后再將處理情況返回給協調者，最終協調者收到響應后便給事務發起者返回處理失敗的結果。

2PC 實現得還是比較雞肋的，因為事實上它只解決了各個事務的原子性問題，隨之也帶來了很多的問題。

單點故障問題：如果協調者掛了那么整個系統都處于不可用的狀態了。
阻塞問題：即當協調者發送 prepare 請求，參與者收到之后如果能處理那么它將會進行事務的處理但并不提交，這個時候會一直占用著資源不釋放，如果此時協調者掛了，那么這些資源都不會再釋放了，這會極大影響性能。
數據不一致問題：比如當第二階段，協調者只發送了一部分的 commit 請求就掛了，那么也就意味著，收到消息的參與者會進行事務的提交，而后面沒收到的則不會進行事務提交，那么這時候就會產生數據不一致性問題

3PC（三階段提交）

因為 2PC 存在的一系列問題，比如單點，容錯機制缺陷等等，從而產生了 3PC（三階段提交） 。那么這三階段又分別是什么呢？

CanCommit 階段：協調者向所有參與者發送 CanCommit 請求，參與者收到請求后會根據自身情況查看是否能執行事務，如果可以則返回 YES 響應并進入預備狀態，否則返回 NO
PreCommit 階段：協調者根據參與者返回的響應來決定是否可以進行下面的 PreCommit 操作。如果上面參與者返回的都是 YES，那么協調者將向所有參與者發送 PreCommit 預提交請求，參與者收到預提交請求后，會進行事務的執行操作，并將 Undo 和 Redo 信息寫入事務日志中 ，最后如果參與者順利執行了事務則給協調者返回成功的響應。如果在第一階段協調者收到了 任何一個 NO 的信息，或者 在一定時間內 并沒有收到全部的參與者的響應，那么就會中斷事務，它會向所有參與者發送中斷請求（abort），參與者收到中斷請求之后會立即中斷事務，或者在一定時間內沒有收到協調者的請求，它也會中斷事務。
DoCommit 階段：這個階段其實和 2PC 的第二階段差不多，如果協調者收到了所有參與者在 PreCommit 階段的 YES 響應，那么協調者將會給所有參與者發送 DoCommit 請求，參與者收到 DoCommit 請求后則會進行事務的提交工作，完成后則會給協調者返回響應，協調者收到所有參與者返回的事務提交成功的響應之后則完成事務。若協調者在 PreCommit 階段 收到了任何一個 NO 或者在一定時間內沒有收到所有參與者的響應 ，那么就會進行中斷請求的發送，參與者收到中斷請求后則會 通過上面記錄的回滾日志 來進行事務的回滾操作，并向協調者反饋回滾狀況，協調者收到參與者返回的消息后，中斷事務。

這里是 3PC 在成功的環境下的流程圖，可以看到 3PC 在很多地方進行了超時中斷的處理，比如協調者在指定時間內未收到全部的確認消息則進行事務中斷的處理，這樣能 減少同步阻塞的時間 。還有需要注意的是，3PC 在 DoCommit 階段參與者如未收到協調者發送的提交事務的請求，它會在一定時間內進行事務的提交。為什么這么做呢？是因為這個時候肯定保證了在第一階段所有的協調者全部返回了可以執行事務的響應，這個時候有理由相信其他系統都能進行事務的執行和提交，所以不管協調者有沒有發消息給參與者，進入第三階段參與者都會進行事務的提交操作。

總之，3PC 通過一系列的超時機制很好的緩解了阻塞問題，但是最重要的一致性并沒有得到根本的解決，比如在 DoCommit 階段，當一個參與者收到了請求之后其他參與者和協調者掛了或者出現了網絡分區，這個時候收到消息的參與者都會進行事務提交，這就會出現數據不一致性問題。

所以，要解決一致性問題還需要靠 Paxos 算法

Paxos 算法

Paxos 算法是基于消息傳遞且具有高度容錯特性的一致性算法，是目前公認的解決分布式一致性問題最有效的算法之一，其解決的問題就是在分布式系統中如何就某個值（決議）達成一致 。

在 Paxos 中主要有三個角色，分別為 Proposer提案者、Acceptor表決者、Learner學習者。Paxos 算法和 2PC 一樣，也有兩個階段，分別為 Prepare 和 accept 階段。

prepare 階段

Proposer提案者：負責提出 proposal，每個提案者在提出提案時都會首先獲取到一個 具有全局唯一性的、遞增的提案編號 N，即在整個集群中是唯一的編號 N，然后將該編號賦予其要提出的提案，在第一階段是只將提案編號發送給所有的表決者。
Acceptor表決者：每個表決者在 accept 某提案后，會將該提案編號 N 記錄在本地，這樣每個表決者中保存的已經被 accept 的提案中會存在一個編號最大的提案，其編號假設為 maxN。每個表決者僅會 accept 編號大于自己本地 maxN 的提案，在批準提案時表決者會將以前接受過的最大編號的提案作為響應反饋給 Proposer 。

下面是 prepare 階段的流程圖：

accept 階段

當一個提案被 Proposer 提出后，如果 Proposer 收到了超過半數的 Acceptor 的批準（Proposer 本身同意），那么此時 Proposer 會給所有的 Acceptor 發送真正的提案（你可以理解為第一階段為試探），這個時候 Proposer 就會發送提案的內容和提案編號。

表決者收到提案請求后會再次比較本身已經批準過的最大提案編號和該提案編號，如果該提案編號 大于等于 已經批準過的最大提案編號，那么就 accept 該提案（此時執行提案內容但不提交），隨后將情況返回給 Proposer 。如果不滿足則不回應或者返回 NO 。

當 Proposer 收到超過半數的 accept ，那么它這個時候會向所有的 acceptor 發送提案的提交請求。需要注意的是，因為上述僅僅是超過半數的 acceptor 批準執行了該提案內容，其他沒有批準的并沒有執行該提案內容，所以這個時候需要向未批準的 acceptor 發送提案內容和提案編號并讓它無條件執行和提交，而對于前面已經批準過該提案的 acceptor 來說 僅僅需要發送該提案的編號 ，讓 acceptor 執行提交就行了。

而如果 Proposer 如果沒有收到超過半數的 accept 那么它將會將遞增該 Proposal 的編號，然后 重新進入 Prepare 階段 。

對于 Learner 來說如何去學習 Acceptor 批準的提案內容，這有很多方式，讀者可以自己去了解一下，這里不做過多解釋。

paxos 算法的死循環問題

比如說，此時提案者 P1 提出一個方案 M1，完成了 Prepare 階段的工作，這個時候 acceptor 則批準了 M1，但是此時提案者 P2 同時也提出了一個方案 M2，它也完成了 Prepare 階段的工作。然后 P1 的方案已經不能在第二階段被批準了（因為 acceptor 已經批準了比 M1 更大的 M2），所以 P1 自增方案變為 M3 重新進入 Prepare 階段，然后 acceptor ，又批準了新的 M3 方案，它又不能批準 M2 了，這個時候 M2 又自增進入 Prepare 階段。

就這樣無休無止的永遠提案下去，這就是 paxos 算法的死循環問題。

那么如何解決呢？很簡單，人多了容易吵架，那么現在 就允許一個能提案 就行了。

ZAB 協議

Paxos 算法應該可以說是 ZooKeeper 的靈魂了。但是，ZooKeeper 并沒有完全采用 Paxos 算法，而是專門定制了一個 ZAB 協議作為其保證數據一致性的核心算法。另外，在 ZooKeeper 的官方文檔中也指出，ZAB 協議并不像 Paxos 算法那樣，是一種通用的分布式一致性算法，它是一種特別為 Zookeeper 設計的崩潰可恢復的原子消息廣播算法。

ZAB 協議介紹

ZAB（ZooKeeper Atomic Broadcast 原子廣播）協議是為分布式協調服務 ZooKeeper 專門設計的一種支持崩潰恢復的原子廣播協議。在 ZooKeeper 中，主要依賴 ZAB 協議來實現分布式數據一致性，基于該協議，ZooKeeper 實現了一種主備模式的系統架構來保持集群中各個副本之間的數據一致性。

ZAB 協議包括兩種基本的模式，分別是

崩潰恢復：當整個服務框架在啟動過程中，或是當 Leader 服務器出現網絡中斷、崩潰退出與重啟等異常情況時，ZAB 協議就會進入恢復模式并選舉產生新的 Leader 服務器。當選舉產生了新的 Leader 服務器，同時集群中已經有過半的機器與該 Leader 服務器完成了狀態同步之后，ZAB 協議就會退出恢復模式。其中，所謂的狀態同步是指數據同步，用來保證集群中存在過半的機器能夠和 Leader 服務器的數據狀態保持一致
消息廣播：當集群中已經有過半的 Follower 服務器完成了和 Leader 服務器的狀態同步，那么整個服務框架就可以進入消息廣播模式了。 當一臺同樣遵守 ZAB 協議的服務器啟動后加入到集群中時，如果此時集群中已經存在一個 Leader 服務器在負責進行消息廣播，那么新加入的服務器就會自覺地進入數據恢復模式：找到 Leader 所在的服務器，并與其進行數據同步，然后一起參與到消息廣播流程中去。

消息廣播模式

說白了就是 ZAB 協議是如何處理寫請求的，只有 Leader 能處理寫請求嘛？那么 Follower 和 Observer 是不是也需要 同步更新數據 呢？總不能數據只在 Leader 中更新了，其他角色都沒有得到更新吧？

不就是 在整個集群中保持數據的一致性 嘛？

第一步肯定需要 Leader 將寫請求廣播出去，讓 Leader 問問 Followers 是否同意更新，如果超過半數以上的同意那么就進行 Follower 和 Observer 的更新（和 Paxos 一樣）。

這兩個Queue 哪冒出來的？ZAB 需要讓 Follower 和 Observer 保證順序性 。何為順序性，比如現在有一個寫請求 A，此時 Leader 將請求 A 廣播出去，因為只需要半數同意就行，所以可能這個時候有一個 Follower F1 因為網絡原因沒有收到，而 Leader 又廣播了一個請求 B，因為網絡原因，F1 竟然先收到了請求 B 然后才收到了請求 A，這個時候請求處理的順序不同就會導致數據的不同，從而 產生數據不一致問題 。

所以在 Leader 這端，它為每個其他的 zkServer 準備了一個隊列，采用先進先出的方式發送消息。由于協議是 通過 TCP 來進行網絡通信的，保證了消息的發送順序性，接受順序性也得到了保證。

除此之外，在 ZAB 中還定義了一個 全局單調遞增的事務 ID ZXID ，它是一個 64 位 long 型，其中高 32 位表示 epoch 年代，低 32 位表示事務 id。epoch 是會根據 Leader 的變化而變化的，當一個 Leader 掛了，新的 Leader 上位的時候，年代（epoch）就變了。而低 32 位可以簡單理解為遞增的事務 id。

定義這個的原因也是為了順序性，每個 proposal 在 Leader 中生成后需要 通過其 ZXID 來進行排序 ，才能得到處理。

崩潰恢復模式

說到崩潰恢復首先要提到 ZAB 中的 Leader 選舉算法，當系統出現崩潰影響最大應該是 Leader 的崩潰，因為我們只有一個 Leader ，所以當 Leader 出現問題的時候我們勢必需要重新選舉 Leader 。

崩潰恢復 是什么？主要就是 當集群中有機器掛了，整個集群如何保證數據一致性？

如果只是 Follower 掛了，而且掛的沒超過半數的時候，因為在 Leader 中會維護隊列，所以不用擔心后面的數據沒接收到導致數據不一致性。

如果 Leader 掛了那就麻煩了，肯定需要先暫停服務變為 Looking 狀態然后進行 Leader 的重新選舉，但這個就要分為兩種情況了，分別是 確保已經被 Leader 提交的提案最終能夠被所有的 Follower 提交 和 跳過那些已經被丟棄的提案 。

確保已經被 Leader 提交的提案最終能夠被所有的 Follower 提交是什么意思呢？

假設 Leader (server2) 發送 commit 請求（忘了請看上面的消息廣播模式），他發送給了 server3，然后要發給 server1 的時候突然掛了。這個時候重新選舉的時候我們如果把 server1 作為 Leader 的話，那么肯定會產生數據不一致性，因為 server3 肯定會提交剛剛 server2 發送的 commit 請求的提案，而 server1 根本沒收到所以會丟棄。

事實上這個時候 server1 已經不可能成為 Leader 了，因為 server1 和 server3 進行投票選舉的時候會比較 ZXID ，而此時 server3 的 ZXID 肯定比 server1 的大了。

跳過那些已經被丟棄的提案又是什么意思呢？

假設 Leader (server2) 此時同意了提案 N1，自身提交了這個事務并且要發送給所有 Follower 要 commit 的請求，卻在這個時候掛了，此時肯定要重新進行 Leader 的選舉，比如說此時選 server1 為 Leader （這無所謂）。但是過了一會，這個 掛掉的 Leader 又重新恢復了 ，此時它肯定會作為 Follower 的身份進入集群中，需要注意的是剛剛 server2 已經同意提交了提案 N1，但其他 server 并沒有收到它的 commit 信息，所以其他 server 不可能再提交這個提案 N1 了，這樣就會出現數據不一致性問題了，所以 該提案 N1 最終需要被拋棄掉 。

posted @ 2025-02-24 08:15 程序員Seven 閱讀(479) 評論(0) 收藏舉報

刷新頁面返回頂部

SevenCoding