zookeeper - 介紹

11.1.1. Zookeeper 概念

Zookeeper 是一個分佈式協調服務，可用於服務發現，分佈式鎖，分佈式領導選舉，配置管理等。 Zookeeper 提供了一個相似於 Linux 文件系統的樹形結構（可認爲是輕量級的內存文件系統，但 只適合存少許信息，徹底不適合存儲大量文件或者大文件），同時提供了對於每一個節點的監控與 通知機制。

11.1.1. Zookeeper 角色

Zookeeper 集羣是一個基於主從複製的高可用集羣，每一個服務器承擔以下三種角色中的一種

11.1.1.1. Leader

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

11.1.1.2. Follower

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

11.1.1.3. Observer 角色

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

 11.1.1.1. ZAB 協議

事務編號 Zxid（事務請求計數器+ epoch）

在 ZAB ( ZooKeeper Atomic Broadcast , ZooKeeper 原子消息廣播協議） 協議的事務編號 Zxid 設計中，Zxid 是一個 64 位的數字，其中低 32 位是一個簡單的單調遞增的計數器，針對客戶端每 一個事務請求，計數器加 1；而高 32 位則表明 Leader 週期 epoch 的編號，每一個當選產生一個新 的 Leader 服務器，就會從這個 Leader 服務器上取出其本地日誌中最大事務的 ZXID，並從中讀取 epoch 值，而後加 1，以此做爲新的 epoch，並將低 32 位從 0 開始計數。 Zxid（Transaction id）相似於 RDBMS 中的事務 ID，用於標識一次更新操做的 Proposal（提議） ID。爲了保證順序性，該 zkid 必須單調遞增。

epoch

epoch：能夠理解爲當前集羣所處的年代或者週期，每一個 leader 就像皇帝，都有本身的年號，所 以每次改朝換代，leader 變動以後，都會在前一個年代的基礎上加 1。這樣就算舊的 leader 崩潰 恢復以後，也沒有人聽他的了，由於 follower 只遵從當前年代的 leader 的命令。

Zab 協議有兩種模式-恢復模式（選主）、廣播模式（同步）

Zab 協議有兩種模式，它們分別是恢復模式（選主）和廣播模式（同步）。當服務啓動或者在領導 者崩潰後，Zab 就進入了恢復模式，當領導者被選舉出來，且大多數 Server 完成了和 leader 的狀 態同步之後，恢復模式就結束了。狀態同步保證了 leader 和 Server 具備相同的系統狀態。

ZAB 協議 4 階段 Leader election（選舉階段-選出準 Leader）

1. Leader election（選舉階段）：

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

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

2. Discovery（發現階段）：在這個階段，followers 跟準 leader 進行通訊，同步 followers 最近接收的事務提議。這個一階段的主要目的是發現當前大多數節點接收的最新提議，而且 準 leader 生成新的 epoch，讓 followers 接受，更新它們的 accepted Epoch 一個 follower 只會鏈接一個 leader，若是有一個節點 f 認爲另外一個 follower p 是 leader，f 在嘗試鏈接 p 時會被拒絕，f 被拒絕以後，就會進入從新選舉階段。 Synchronization（同步階段-同步 follower 副本）

3. Synchronization（同步階段）：同步階段主要是利用 leader 前一階段得到的最新提議歷史， 同步集羣中全部的副本。只有當 大多數節點都同步完成，準 leader 纔會成爲真正的 leader。 follower 只會接收 zxid 比本身的 lastZxid 大的提議。 Broadcast（廣播階段-leader 消息廣播）

4. Broadcast（廣播階段）：到了這個階段，Zookeeper 集羣才能正式對外提供事務服務， 而且 leader 能夠進行消息廣播。同時若是有新的節點加入，還須要對新節點進行同步。

ZAB 提交事務並不像 2PC 同樣須要所有 follower 都 ACK，只須要獲得超過半數的節點的 ACK 就 能夠了。

ZAB 協議 JAVA 實現（FLE-發現階段和同步合併爲 Recovery Phase（恢復階段））

協議的 Java 版本實現跟上面的定義有些不一樣，選舉階段使用的是 Fast Leader Election（FLE）， 它包含了 選舉的發現職責。由於 FLE 會選舉擁有最新提議歷史的節點做爲 leader，這樣就省去了 發現最新提議的步驟。實際的實現將 發現階段 和 同步合併爲 Recovery Phase（恢復階段）。所 以，ZAB 的實現只有三個階段：Fast Leader Election；Recovery Phase；Broadcast Phase。

11.1.1.2. 投票機制

每一個 sever 首先給本身投票，而後用本身的選票和其餘 sever 選票對比，權重大的勝出，使用權 重較大的更新自身選票箱。具體選舉過程以下：

1. 每一個 Server 啓動之後都詢問其它的 Server 它要投票給誰。對於其餘 server 的詢問， server 每次根據本身的狀態都回複本身推薦的 leader 的 id 和上一次處理事務的 zxid（系 統啓動時每一個 server 都會推薦本身）

2. 收到全部 Server 回覆之後，就計算出 zxid 最大的哪一個 Server，並將這個 Server 相關信 息設置成下一次要投票的 Server。

3. 計算這過程當中得到票數最多的的 sever 爲獲勝者，若是獲勝者的票數超過半數，則改 server 被選爲 leader。不然，繼續這個過程，直到 leader 被選舉出來 4. leader 就會開始等待 server 鏈接

5. Follower 鏈接 leader，將最大的 zxid 發送給 leader

6. Leader 根據 follower 的 zxid 肯定同步點，至此選舉階段完成。

7. 選舉階段完成 Leader 同步後通知 follower 已經成爲 uptodate 狀態 8. Follower 收到 uptodate 消息後，又能夠從新接受 client 的請求進行服務了 

 

目前有 5 臺服務器，每臺服務器均沒有數據，它們的編號分別是 1,2,3,4,5,按編號依次啓動，它們 的選擇舉過程以下：

1. 服務器 1 啓動，給本身投票，而後發投票信息，因爲其它機器尚未啓動因此它收不到反 饋信息，服務器 1 的狀態一直屬於 Looking。

2. 服務器 2 啓動，給本身投票，同時與以前啓動的服務器 1 交換結果，因爲服務器 2 的編號 大因此服務器 2 勝出，但此時投票數沒有大於半數，因此兩個服務器的狀態依然是 LOOKING。

3. 服務器 3 啓動，給本身投票，同時與以前啓動的服務器 1,2 交換信息，因爲服務器 3 的編 號最大因此服務器 3 勝出，此時投票數正好大於半數，因此服務器 3 成爲領導者，服務器 1,2 成爲小弟。

4. 服務器 4 啓動，給本身投票，同時與以前啓動的服務器 1,2,3 交換信息，儘管服務器 4 的 編號大，但以前服務器 3 已經勝出，因此服務器 4 只能成爲小弟。

5. 服務器 5 啓動，後面的邏輯同服務器 4 成爲小弟。