Zookeeper 原理

Zookeeper 概念

Zookeeper 是一個分佈式協調服務，可以用於服務發現，分佈式鎖，分佈式選舉，配置管理等場景。

Zookeeper 提供了一個類似於 Linux 文件系統的樹形結構（可以認爲是輕量級的內存文件系統，但是隻適合存少量信息，完全不適合存儲大量文件或者大文件），同時提供了對於每個節點的通知機制。

Zookeeper 角色

leader

一個 Zookeeper 集羣同一時間只會有一個實際工作的 Leader，它會發起並維護與各 Follwer及 Observer 間的心跳。
所有的寫操作必須要通過 Leader 完成再由 Leader 將寫操作廣播給其它服務器。只要有超過半數節點（不包括 observeer 節點）寫入成功，該寫請求就會被提交（類 2PC 協議）。

follwer

一個 Zookeeper 集羣可能同時存在多個 Follower，它會響應 Leader 的心跳，
Follower 可直接處理並返回客戶端的讀請求，同時會將寫請求轉發給 Leader 處理
並且負責在 Leader 處理寫請求時對請求進行投票。

observer

角色與 Follower 類似，但是無投票權。 Zookeeper 需保證高可用和強一致性，爲了支持更多的客戶端，需要增加更多 Server； Server 增多，投票階段延遲增大，影響性能；引入 Observer，Observer 不參與投票； Observers 接受客戶端的連接，並將寫請求轉發給 leader 節點； 加入更
多 Observer 節點，提高伸縮性，同時不影響吞吐率。

什麼是 zab 協議？

ZAB 協議是用來實現分佈式系統中的一致性的。
是爲了分佈式協調服務 Zookeeper 專門設計的一種支持恢復的原子廣播協議。有了這個協議，Zookeeper 實現了一種主備架構來保持機器中各個副本的數據一致性。

ZAB 協議

ZAB 協議中有兩個重要的元素：事務編號Zxid、epoch。

Zxid

協議的事務編號 Zxid 設計中， Zxid 是一個 64位的數字，其中低 32 位是一個簡單的單調遞增的計數器，針對客戶端每一個事務請求，計數器加 1; 而高32 位則代表 Leader 週期 epoch 的編號，每個當選產生一個新的 Leader 服務器，就會從這個 Leader 服務器上取出其本地日誌中的最大事務 ZXID ,並從中讀取 epoch 值，然後加 1 ，以此作爲新的 epoch.並降低 32 位從 0 開始計數。

Zxid 類似 RDBMS 中的事務 ID ，用於標記一次更新操作的 Proposal (提議) ID, 爲了保證順序性，該 zxid 必須單調遞增。

epoch

epoch：可以理解爲當前集羣所處的年代或者週期，每個 leader 都有自己的年號，所以每次改朝換代之後，leader 變更之後，都會在前一個年代的基礎上加1, 這樣就算舊 leader 的崩潰恢復後，也沒有人聽他的，因爲 follower 只聽從當前代的 leader 的命令。

Zab 協議的4階段

Phase 0. Leader election(選舉階段)

Leader election（選舉階段）：節點在一開始都處於選舉階段，只要有一個節點得到超半數節點的票數，它就可以當選準 leader。只有到達廣播階段（broadcast）準 leader 纔會成爲真正的 leader。這一階段的目的是就是爲了選出一個準 leader，然後進入下一個階段。

Phase 1. Discovery （發現階段-接受提議，生成epoch、接受 epoch）

在這個階段， followers 跟準 leader 進行通信，同步 followers
最近接收的事務提議。這個一階段的主要目的是發現當前大多數節點接收的最新提議，並且準 leader 生成新的 epoch，讓 followers 接受，更新它們的 accepted Epoch,一個 follower 只會連接一個 leader，如果有一個節點 f 認爲另一個 follower p 是 leader， f 在嘗試連接 p 時會被拒絕， f 被拒絕之後，就會進入選舉階段。

Phase 2. Synchronization (同步階段-同步 follower 副本)

Synchronization（同步階段）: 同步階段主要是利用 leader 前一階段獲得的最新提議歷史，同步集羣中所有的副本。只有當大多數節點都同步完成，準 leader 纔會成爲真正的 leader。follower 只會接收 zxid 比自己的 lastZxid 大的提議。

Phase 3. Broadcast（廣播階段）

到了這個階段， Zookeeper 集羣才能正式對外提供事務服務，
並且 leader 可以進行消息廣播。同時如果有新的節點加入，還需要對新節點進行同步。ZAB 提交事務並不像 2PC 一樣需要全部 follower 都 ACK，只需要得到超過半數的節點的 ACK 就可以了。

ZAB 協議實現

協議的 Java 版本實現上面的定義不一樣，宣酒節點使用的是 Fast Leader Election (FLE) 它包含了Phase 1 的發現職責，因爲 FLE 會選舉擁有最新提議歷史的節點作爲 leader, 這樣就可以省去發現新提議的步驟，實際的實現將 Phase 1 和 Phase 2 合併成 Recovery Phase 。所以 ZAB 實現只有三個階段。

Fast Leader Election
Recovery Phase
Broadcast Phase
https://juejin.im/post/5b924b0de51d450e9a2de615

主從架構下，leader 崩潰，數據一致性怎麼保證？

leader 崩潰之後，集羣會選出新的 leader，然後就會進入恢復階段，新的 leader 具有所有已經提交的提議，因此它會保證讓 followers 同步已提交的提議，丟棄未提交的提議（以 leader 的記錄爲準），這就保證了整個集羣的數據一致性。

選舉 leader 的時候，整個集羣無法處理寫請求的，如何快速進行 leader 選舉？

這是通過 Fast Leader Election 實現的，leader 的選舉只需要超過半數的節點投票即可，這樣不需要等待所有節點的選票，能夠儘早選出 leader。

ZAB 兩種模式

恢復模式

當服務啓動或者在 leader 崩潰的時候， Zab 進入恢復模式，當領導者被選舉出來，並且大多數 server 和 leader 狀態同步後，恢復模式結束。

廣播模式

Zookeeper 工作原理

Zookeeper 的核心是原子廣播，這個機制保證了各個 server 之間的同步。實現這個機制的協議叫做 Zab 協議。 Zab 協議有兩種模式，它們分別是恢復模式和廣播模式。
當服務啓動或者在領導者崩潰後， Zab 就進入了恢復模式，當領導者被選舉出來，且大多數 server 的完成了和 leader 的狀態同步以後，恢復模式就結束了。
狀態同步保證了 leader 和 server 具有相同的系統狀態
一旦 leader 已經和多數的 follower 進行了狀態同步後，他就可以開始廣播消息了，即進入廣播狀態。這時候當一個 server 加入 zookeeper 服務中，它會在恢復模式下啓動，發現 leader，並和 leader 進行狀態同步。待到同步結束，它也參與消息廣播。 Zookeeper 服務一直維持在 Broadcast 狀態，直到 leader 崩潰了或者 leader 失去了大部分的 followers 支持。
廣播模式需要保證 proposal 被按順序處理，因此 zk 採用了遞增的事務 id 號(zxid)來保證。所有的提議(proposal)都在被提出的時候加上了 zxid。
實現中 zxid 是一個 64 爲的數字，它高 32 位是 epoch 用來標識 leader 關係是否改變，每次一個 leader 被選出來，它都會有一個新的 epoch。低 32 位是個遞增計數。
當 leader 崩潰或者 leader 失去大多數的 follower，這時候 zk 進入恢復模式，恢復模式需要重新選舉出一個新的 leader，讓所有的 server 都恢復到一個正確的狀態。

【深入理解Zookeeper原理】Zab 協議