1、Zookeeper簡介

Zookeeper是一個高可用、高效能的分散式協調服務，可用於服務發現、分散式鎖、分散式領導選舉、配置管理等。
這一切的基礎，都是Zookeeper提供了一個類似於Linux檔案系統的樹形結構Znode（可認為是輕量級的記憶體檔案系統，但只適合存少量資訊，完全不適合儲存大量檔案或者大檔案），同時提供了對於每個節點的監控與通知機制；

2、Zookeeper叢集

3、Zookeeper元件

Zookeeper叢集是一個基於主從複製的高可用叢集，每個伺服器承擔如下三種角色中的一種；

• Leader：一個Zookeeper叢集同一時間只會有一個實際工作的Leader，他會發起並維護與各Follower及Observer間的心跳；所有的寫操作必須要通過Leader完成，再由Leader將寫操作廣播給其他伺服器

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

• Observer ：如果Zookeeper叢集的讀取負載很高，或者客戶端多到跨機房，可以設定一些observer伺服器，以提高讀取的吞吐量，Observer角色與Follower類似，但是有兩個區別，一是沒有投票權，即不參加選舉也不響應提議，二是Observer不需要將事務持久化到磁碟，一旦observer被重啟，需要從leader重新同步整個名字空間

4、Zookeeper特性：

Zookeeper是一個由多個server組成的叢集

• 一個leader，多個follower、observer
• 每個server儲存一份資料副本
• 全域性資料一致
• 分散式讀flower，寫由leader實施
• 更新請求轉發，由leader實施
• 更新請求順序進行(FIFO)，來自同一個client的更新請求按器傳送順序依次執行
• 資料更新原子性，一次資料更新要麼成功，要麼失敗
• 全域性唯一資料檢視，client無論連線到哪個server，資料檢視都是一致的
• 實時性，在一定時間範圍內，client能讀到最新資料

5、應用場景

• 分散式服務註冊與訂閱
  在分散式環境中，為了保證高可用性，通常同一個應用或同一個服務的提供方都會部署多份，達到對等服務；而消費者就需要在這些對等的伺服器中選擇一個來執行相關的業務邏輯，比較典型的服務註冊與訂閱，消費端&消費端&生產端（負責均衡類似方案）
  總結：系統之間存在某種訂閱關係
  適用：dubbo的provider和consumer

  
  
  

  image.png

• 分散式配置中心
  分散式配置中心，屬於釋出與訂閱模型，顧名思義就是釋出者將資料釋出到ZK節點上，供訂閱者獲取資料，實現配置資訊的集中式管理和動態更新
  總結：感應變化 pull模式（C>>S）/push模式（S>>C）
  適用：全域性的配置資訊，服務式服務框架的服務地址列表
  注意點：資料量很小，但是資料更新可能會比較快的場景
  代表：百度的disconf
  github：https://github.com/knightliao/disconf

• 命名服務
  在分散式系統中，通過使用命名服務，客戶端應用能夠根據指定名字來獲取資源、服務的地址、提供者等資訊；被命名的實體通常是叢集中的機器提供的服務地址、程式物件等，這些我們都可以統稱他們為名字（Name）
  總結：全域性唯一的path、全域性唯一性ID
  適用：較為常見的就是一些分散式服務框架中的服務地址列表；通過呼叫ZK提供的建立節點的API，能夠很容易建立一個全域性唯一的path，這個path就可以作為一個名稱
  注意：所有向ZK上註冊的地址都是臨時節點，這樣就能夠保證服務提供者和消費者能夠自動感應資源的變化
  代表：dubbo

• 分散式通知協調
  Zookeeper中特有的，watcher註冊不非同步通知機制，能夠很好的實現分散式環境下不同系統通知與協調，實現對資料變更的實時處理；
  使用方法通常是不同系統都對ZK上同一個znode節點進行註冊，監聽znode的變化（包括znode本身內容及子節點的），其中一個系統update了znode，那麼另一個系統能夠收到通知，並作出相應處理
  總結：需要雙系統協調做一件事情
  適用：排程系統，推送系統，心跳檢測等
  需要兩方系統一起做的事情，適用zookeeper來進行分散式通知和協調能夠大大降低系統之間的耦合

• 分散式鎖
  分散式鎖，主要是得益於zookeeper為我們保證了資料的強一致性。

6、Zookeeper寫操作

• 寫Leader：通過Leader進行寫操作流程
  1、客戶端向Leader發起寫請求
  2、Leader將寫請求以Proposal的形式發給所有Follower並等待應答(ACK)
  3、Follower收到Leader的Proposal後返回ACK
  4、Leader得到過半數的ACK（Leader對自己預設有一個ACK）後，向所有的Follower和Observer傳送Commit
  5、leader將處理結果返回客戶端

這裡需要注意：
1、Leader並不需要得到Observer的ACK，即Observer無投票權
2、Leader不需要得到所有Follower的ACK，只要收到過半的ACK即可，同時Leader本身對自己有一個ACK。上圖中有4個Follower，只需其中兩個返回ACK即可，因為 (2+1)/(4+1) > 1/2
3、Observer雖然無投票權，但仍需同步Leader的資料從而在處理讀請求時可以返回儘可能新的資料

• 寫Follower/Observer：通過Follower/Observer進行寫操作

從上圖中可以看出，Follower/Observer均可接受寫請求，但不能直接處理，而需要將寫請求轉發給Leader處理；
除了多了非同步請求轉發，其他流程與直接寫Leader無任何區別

7、Zookeeper讀操作

Leader/Follower/Observer都可直接處理讀請求，從本地記憶體中讀取資料並返回給客戶端即可；
由於處理讀請求不需要伺服器之間的互動，Follow/Observer越多，整體可處理的讀請求量越大，也即讀效能越好

8、Session會話

客戶端連結zookeeper叢集是通過Session連結（TCP長連結）
客戶端連結以後可以對節點（儲存在zookeeper上，znode）增刪查改操作

9、資料模型Znode

Znode節點型別：2大類，4種型別，持久、臨時、持久有序、臨時有序

• PERSISTENT ：持久型別，如果不手動刪除，是一致存在的
• PERSISTENT_SEQUENTIAL ：持久有序
• EPHEMERAL ：臨時型別，客戶端session失效就會隨著刪除節點，沒有子節點
• EPHEMERAL_SEQUENTIAL：臨時有序，自增

Znode節點狀態

10、ACL（Access Control List）

對znode節點做增刪查改時我們可以監控其動作（Watcher機制），還可以對節點設定許可權訪問

• 內建的ACL schemes：
  world：預設方式，相當於全世界都能訪問
  auth：代表已經認證通過的使用者（cli中可以通過addauth digest user:pwd 來新增當前上下文中的授權使用者）
  digest：即使用者名稱：密碼這種方式認證，這也是業務系統中最常用的
  ip：使用IP地址認證

• ACL支援許可權：
  CREATE：能建立子節點
  READ：能獲取節點資料和列出其子節點
  WRITE：能設定節點資料
  DELETE：能刪除子節點
  ADMIN：能設定許可權

11、Watcher 監聽

12、ZAB（原子廣播）協議

為了保證寫操作的一致性與可用性，Zookeeper專門設計了一種名為原子廣播（ZAB）的支援奔潰恢復的一致性協議，基於該協議，Zookeeper實現了一種主從模式的系統架構保持叢集中各個副本之間的資料一致性；
根據ZAB協議，所有的寫操作都必須通過Leader完成，Leader寫入本地日誌後再複製到所有的Follower節點；
一旦Leader節點無法工作，ZAB協議能夠自動從Follower節點中重新選出一個合適的替代者，即新的Leader，該過程即為領導選舉；該leader選舉過程，是ZAB協議中最為重要和複雜的過程；

ZAB協議模式：恢復模式 廣播模式
當服務啟動或者在領導者崩潰後，Zab就進入了恢復密室，當領導者被選舉出來，且大多數server完成了和leader的狀態同步以後，恢復模式就結束。狀態同步保證了leader和server具有相同的系統狀態，一旦leader已經和多數的follower進行了狀態同步後，leader就可以廣播訊息了，即進入廣播模式；
這時候當一個server 加入zookeeper服務中，它會在恢復模式下起送，發現leader，並和leader進行狀態同步，待到同步結束，它也會參與訊息廣播；

Zoopkeeper服務一直維持在Broadcast狀態，直到leader奔潰了或者leader失去了大部分的followers支援。

廣播模式需要保證proposal被按順序處理，因此zk採用了遞增的事務id號（zxid）來保證，所有的提議（proposal）都在被提出的時候加上了zxid，實現中，zxid是一個64位的數字，高32位是epoch用來標識leader關係是否改變，每次一個leader被選出來，它都會有一個新的epoch，低32位是個遞增計數；

當leader奔潰或者leader失去大多數的follower，這時候zk進入恢復模式，恢復模式需要重新選舉出一個新的leader，讓所有的server都恢復到一個正確的狀態

13、Leader選舉

LOOKING，FOLLOWING，LEADING，OBSERVING