Zookeeper基礎學習筆記

其實網絡上關於Zookeeper的文章多如牛毛，起初，我也只是想寫個學習筆記，作個記錄。可是既然動筆了，我想就不單是作個筆記，而是但願寫一些對讀者有幫助的內容。

Zookeeper做爲一個流行的分佈式協調服務，要了解他，咱們首先問本身兩個問題，Why and How？咱們爲何要用Zookeeper？Zookeeper是怎麼工做的？

Why（用途）

首先，咱們爲何要用到Zookeeper？咱們能夠把軟件系統類比爲一個公司，當公司規模小的時候，老闆就能決定全部的事情；

但當公司規模發展壯大後，老闆一我的管理公司有些吃力，但又不放心把全部權力交給另一我的，這時老闆想了個辦法，成立了一個CEO團隊，團隊採用民主化運做進行集體決策。

ECO團隊的主要任務：

1. 制定公司各項規章制度並對全公司公佈
2. 收集各部門的提交的意見，決定是否採納
3. 公司規章制度更新後，通知涉及的部門

相似的，Zookeeper做爲分佈式協調服務，他主要經過兩個手段對外提供服務，即服務目錄 + 通知。

1. 維護一個類文件系統的數據結構，存儲信息，給業務提供服務
2. 接收客戶端提交的修改請求，並在內部同步達成一致
3. 當信息發生變化時，消息推送給感興趣的監聽者

Zookeeper的應用場景包括：數據發佈/訂閱、命名服務、配置中心、分佈式鎖、集羣管理、選主與服務發現等等。

基本概念

先了解下Zookeeper裏的一些基本概念。

目錄節點(znode)

Zookeeper類文件系統中的每一個節點稱爲znode，znode裏包含了節點的自身信息和業務數據，根據節點屬性，能夠分爲2大類，分別是持久化節點和臨時節點，每類下有分爲普通節點和按順序編號節點，分別描述以下：

1. PERSISTENT：持久化目錄節點

   • 客戶端斷開後，節點依然存在

2. PERSISTENT_SEQUENTIAL：持久化順序編號目錄節點

   • 客戶端斷開後，節點依然存在
   • Zookeeper會給此類節點名稱進行順序編號

3. EPHEMERAL：臨時目錄節點

   • 客戶端斷開後，節點被刪除

4. EPHEMERAL_SEQUENTIAL：臨時順序編號目錄節點

   • 客戶端斷開後，節點被刪除
   • Zookeeper會給此類節點名稱進行順序編號

監聽機制(Watcher)

客戶端註冊監聽它關心的節點，當節點發生變化（數據改變、刪除、子節點增長/刪除）時，監聽器會被觸發，並將事件信息推送到客戶端。

節點角色

Zookeeper自己做爲一個分佈式服務，有若干節點組成集羣對外提供服務，集羣節點包括Leader、Follower、Observer 3種角色。

• Leader：領導者，爲客戶端寫服務；維護集羣狀態。Leader由集羣選舉產生。
• Follower：跟隨者，爲客戶端提供讀服務；按期向Leader彙報自身狀態；參與寫服務器過半寫成功的決策和Leader選舉。
• Observer：觀察者，爲客戶端提供讀服務；按期向Leader彙報自身狀態；不參與決策和選舉。Observer能夠在不影響寫性能的狀況下提高集羣的讀性能。

客戶端會話

Zookeeper客戶端經過TCP長鏈接鏈接到服務集羣，會話(Session)從第一次鏈接開始就已經創建，以後經過心跳檢測機制來保持有效的會話狀態。客戶端經過這個鏈接發送請求並接收響應，接收到Watch事件的通知。

當因爲網絡故障或者客戶端主動斷開等緣由，致使鏈接斷開，此時只要在會話超時(Session TimeOut)時間以內從新創建鏈接，則以前建立的會話依然有效。

ZXID

對於每一個事務，Zookeeper都會分配一個全局惟一的事務ID(ZXID)。ZXID由64位組成。其中高32位爲紀元號（Epoch：集羣每選舉一次Leader，紀元號加1）；低32爲本紀元內的事務序號（事務序號在每一個紀元會清零）

民主選舉（過半機制）

所謂民主選舉，是指當集羣中超過一半的節點贊成一個事務時，即表示事務執行成功（不包括Observer）。Leader提交一個提案時，只要過半數節點反饋ACK，就職務提案被集羣接受了，Leader不須要等待剩餘節點反饋ACK，直接廣播Commit消息；Leader選舉和數據同步時，亦如此。

提案和事務

Zookeeper收到客戶端的一個寫請求，稱爲提案(Proposal)，把一個提案提交到集羣並應用生效的過程，叫事務

How（ZAB協議）

下面咱們再來看下，做爲一個CEO團隊，它是如何運做的。做爲一個優秀的管理團隊，他的運做要知足CAP原則，即：

• 一致性：團隊成員達成一致
• 可用性：不能某人離職了就玩不轉了
• 分區容錯性：緊急狀態下聯繫不上所有成員的時候要能決策重要事項）

團隊經過如下幾條規則確保CAP：

1. 團隊成員人數不能太少，至少要3人及以上
2. 由團隊成員民主（過半數贊成）選舉產生一個首席CEO，根據任人惟賢能上能下的宗旨，首席CEO乾的很差了，可由團隊從新選舉產生。
3. 公司全部的決策，由首席CEO從各部門收集後產生提案，並由CEO團隊民主表決經過。

Zookeeper的工做原理，和以上相似。主要依賴ZAB(ZooKeeper Atomic Broadcast)一種支持崩潰恢復的原子廣播協議來完成。

ZAB的特性

1. 一致性保證

   1. 可靠提交(Reliable Delivery)：若是一個事務被Leader提交了，那麼最終必定會被全部的節點提交
   2. 全局有序(Total Order)：假設A、B兩個事務，Leader先提交了A，再提交B，那麼能夠保證全部節點都以先A後B的順序提交
   3. 因果有序(Causal Order)：若是發送者在事務A提交後再發送B，那麼B一定在A以後執行
2. 只要過半節點啓動，系統就能正常運行
3. 當節點下線後重啓，必須保證能恢復到當前正在執行的事務

ZAB協議有兩種工做模式，分別是廣播模式和恢復模式。

1. 恢復模式：集羣啓動後，先經過恢復模式選出Leader，並完成節點間數據同步；
2. 廣播模式：恢復完成後，系統進入廣播模式，開始接受客戶端請求，並確保節點間數據同步。

廣播模式(Broadcast)

廣播模式主要用來實現集羣節點間數據的同步，每一個同步操做定義爲一個事務，使用兩階段提交協議完成事務提交，以客戶端寫數據爲例進行說明事務操做：

1. Leader從客戶端接受寫請求（若是Follower接受到寫請求，會轉發給Leader）
2. Leader生成一個新提案(Proposal)，併爲提案分配ZXID，啓動提案提交事務
3. Leader將提案發送給全部Follower
4. Follower將接收到的提案加入歷史隊列(History Queue)，並給Leader回覆ACK
5. 當Leader收到過半Follower的ACK後，Leader Commit提案，並向Follower廣播提案Commit請求
6. Follower接收到提案Commit請求後，Commit本地的提案，事務結束

根據全局有序的規則，Follower提交事務時，須要經過歷史隊列，確認此提案的ZXID是不是最小的，最小才提交，否則就等待其餘ZXID更小的事務先提交

恢復模式(Recovery)

當整個集羣在啓動時，或者Leader失聯後，ZAB協議就會進入恢復模式，恢復模式的流程以下：

1. 集羣經過過民主舉機制產生新的Leader，紀元號加1，開始新紀元
2. 其餘節點重新的Leader同步狀態
3. 過半節點完成狀態同步，退出恢復模式，進入消息廣播模式

Leader選舉流程

Leader選舉是集羣正常運行的前提，當集羣啓動或Leader失聯後，就會進入Leader選舉流程。
選舉期間，集羣間經過選票(Vote) 進行進行互相選舉，選票主要包含兩個信息：

1. 節點ID：集羣配置文件中預配置的每一個節點的ID
2. ZXID：節點已經Commit的最大提案的ID

選舉流程：

1. 全部節點進入LOOKING狀態
2. 每一個節點廣播攜帶自身ID和ZXID的選票，投票推舉本身爲Leader
3. 節點接收其餘節點發送的選票，把選票信息和本身推舉的選票進行PK（選票中ZXID大者勝出，ZXID相同，則ID大者勝出）
4. 若是外部選票獲勝，則保存此選票信息，並把選票廣播出去（同意該選票）
5. 循環上述3-4步驟
6. 當有選票獲得超過半數節點同意，且該選票的全部者也同意該選票，則選舉成功，該選票全部者成爲Leader
7. Leader切換爲LEADING，Follower切換爲FOLLOWING，Observer切換爲OBSERVING狀態，選舉結束，進入數據同步流程。

數據同步流程，是要以Leader數據爲基礎，讓集羣數據達到一致狀態。

數據同步流程

1. 新Leader把本地快照加載到內存，並經過日誌應用快照以後的全部事務，確保Leader數據庫是最新的
2. Follower和Observer把自身的ZXID和Leader的ZXID進行比較，肯定每一個節點的同步策略
3. 根據同步策略，Leader把數據同步到各節點
4. 每一個節點同步結束後，Leader向節點發送NEWLEADER指令
5. 同步完成的節點返回ACK
6. 當Leader收到過半節點反饋的ACK時，認爲同步完成
7. Leader向節點發送UPTODATE指令，通知集羣同步完成，開始對外服務

遺留問題
根據ZAB協議，Leader已經Commit的事務，從新選主後，要能在新集羣生效。可是有一種狀況，對於一個提案Px，原Leader向集羣廣播提案並收到了過半Follower的ACK，此時Leader會自身先執行Commit再向集羣廣播Commit，但還將來得及向集羣廣播Commit消息，Leader就掛了。
此後經過選舉，原Follower成爲了新Leader，新Leader中Px確定是未Commit的，系統如何保證Px生效呢？ 這個還沒看研究源碼，有知道請告知下！！

典型應用場景

數據發佈/訂閱

數據的發佈/訂閱系統，一般也用做配置中心。在分佈式系統中，你可能有成千上萬個服務節點，若是想要對全部服務的某項配置進行更改，因爲數據節點過多，你不可逐臺進行修改，而應該在設計時採用統一的配置中心。以後發佈者只須要將新的配置發送到配置中心，全部服務節點便可自動下載並進行更新，從而實現配置的集中管理和動態更新。
Zookeeper經過Watcher機制能夠實現數據的發佈和訂閱。分佈式系統的全部的服務節點能夠對某個ZNode註冊監聽，以後只須要將新的配置寫入該ZNode，全部服務節點都會收到該事件。

命名服務

在分佈式系統中，一般須要一個全局惟一的名字，如生成全局惟一的訂單號等，Zookeeper能夠經過順序節點的特性來生成全局惟一ID，從而能夠對分佈式系統提供命名服務。

Master選舉

分佈式系統一個重要的模式就是主從模式(Master/Salves)，Zookeeper能夠用於該模式下的Matser選舉。可讓全部服務節點去競爭性地建立同一個ZNode，因爲Zookeeper不能有路徑相同的ZNode，必然只有一個服務節點可以建立成功，這樣該服務節點就能夠成爲Master節點。

分佈式鎖

能夠經過Zookeeper的臨時節點和Watcher機制來實現分佈式鎖，這裏以排它鎖爲例進行說明：
分佈式系統的全部服務節點能夠競爭性地去建立同一個臨時ZNode，因爲Zookeeper不能有路徑相同的ZNode，必然只有一個服務節點可以建立成功，此時能夠認爲該節點得到了鎖。其餘沒有得到鎖的服務節點經過在該ZNode上註冊監聽，從而當鎖釋放時再去競爭得到鎖。鎖的釋放狀況有如下兩種：

1. 當正常執行完業務邏輯後，客戶端主動將臨時ZNode刪除，此時鎖被釋放；
2. 當得到鎖的客戶端發生宕機時，臨時ZNode會被自動刪除，此時認爲鎖已經釋放。

當鎖被釋放後，其餘服務節點則再次去競爭性地進行建立，但每次都只有一個服務節點可以獲取到鎖，這就是排他鎖。

集羣管理

Zookeeper還能解決大多數分佈式系統中的問題：
如能夠經過建立臨時節點來創建心跳檢測機制。若是分佈式系統的某個服務節點宕機了，則其持有的會話會超時，此時該臨時節點會被刪除，相應的監聽事件就會被觸發。

1. 分佈式系統的每一個服務節點還能夠將本身的節點狀態寫入臨時節點，從而完成狀態報告或節點工做進度彙報。
2. 經過數據的訂閱和發佈功能，Zookeeper還能對分佈式系統進行模塊的解耦和任務的調度。
3. 經過監聽機制，還能對分佈式系統的服務節點進行動態上下線，從而實現服務的動態擴容。

參考材料

1. 分析Zookeeper的一致性原理