想精通分佈式以及高併發架構？那你得先搞定ZooKeeper架構原理！

Zookeeper是分佈式一致性問題的工業解決方案，是Apache Hadoop下解決分佈式一致性的一個組件，後被分離出來成爲Apache的頂級項目。

工程來源：是雅虎公司內部項目，聽說雅虎內部不少項目都是以動物命名，這個動物管理員的名字起的非常形象。

被開源出來後獲得開源社區的快速推動，服務端Java語言實現，棒，git有3000+的star：

https://github.com/apache/zookeeper

 

zookeeper集羣結構

集羣的角色，比較典型的是Master/Slave(主備模式)，zk中的概念跟這個不同，包含Leader、Follower、Observer三個角色，leader提供讀和寫的能力，follower只對外提供讀的能力。

會話（session）

客戶端跟服務端交互，是先與服務端創建一個TCP長鏈接，會話開始，經過心跳檢測與服務端保持會話有效，向服務端發送請求和接收響應。

zk將全部的數據都加載在內存一份，同時有事務日誌文件（持久化文件），服務端會定時dump快照數據，重啓機器的時候會根據快照和事務日誌恢復內存數據庫的數據，這跟redis的AOF和RDB概念相似。

zookeeper上的數據結構

zk上的數據的結構跟linux文件系統很像，是個樹狀結構

 

 

節點（node）上的信息字段

 

 

節點類型包括：

• 持久型節點
• 順序持久型節點
• 臨時節點
• 順序臨時節點

 

其中臨時節點特性就是建立它的主體消失後，它就跟着消失了。後續的應用就是利用的節點的特性實現的。

事件監聽器（watcher）

這個應該是zookeeper最重要的概念之一了，zk容許用戶在特定的節點（znode）上註冊watcher，而且在特定事件觸發的時候，zk服務端會將事件通知到感興趣的客戶端上。

僞集羣的搭建：

 

 

zoo.cfg 配置文件

• 拷貝三份文件
• 修改配置zoo.cfg，區別出日誌目錄和端口號，dataDir文件下添加表示機器號的文件myid
• 集羣配置列表，第一個端口是機器間業務通信的端口，第二個端口是用來進行leader選舉的端口
• 分別啓動三臺服務器

啓動成功後，命令行鏈接zk，能夠用指令作些增刪改查的操做

telnet 127.0.0.1 2181

stat：能夠看集羣的狀態信息

 

 

stat信息

每次事務操做，會在dataDir的目錄下的事務日誌，是序列化的二進制文件，zookeeper提供了查看事務日誌的工具類LogFormatter

 

 

LogFormatter轉換後的事務日誌文件

Java客戶端使用

1. zookeeper自帶的
2. 開源的客戶端ZkClient，實現session超時重連，watcher反覆註冊的功能，簡化開發人員的使用
3. 開源客戶端Crurator，解決底層的細節開發工做，目前是apache的頂級項目，是使用最普遍的zk客戶端。
4. 提供了可讀性更新的api接口
5. 提供了各類應用場景的抽象封裝（共享鎖服務、Master選舉機制，分佈式計數器等）
6. guava is to java what cruator is to zookeeper

 

 

 

cruator客戶端例子

zookeeper應用場景

利用zookeeper的特性，能夠比較方便的構建分佈式應用會涉及的核心功能，好比：配置中心、命名服務、分佈式協調/通知、集羣的管理、master選舉、分佈式鎖等

如下應用基本基於zookeeper的兩大特性實現

• 客戶端若是對zookeeper的一個數據節點註冊watcher監聽，那麼當該數據節點的內容或其子節點的列表發生變動是，zookeeper服務器就會想訂閱的客戶端發送變動通知
• 對在zookeeper上建立的臨時節點（sequent類型），一旦客戶端與服務器之間的回話失效，那麼臨時節點會被自動清除

 

--配置中心：

 

 

配置中心

zookeeper利用推拉結合的方式，客戶端向服務端註冊本身須要關注的節點，一旦該數據發生變動，那麼服務器就會向相應的客戶端發送watcher時間通知。

客戶收到這個消息通知以後，再主動到服務端獲取最新的數據。即回調的event中包含具體的數據。

這個應用的的業務員特色：

1. 數據不常常變化
2. 數據量一般比較小，保存的內存裏，訪問很快
3. 配置動態變化，不須要重啓機器，數據變化，會通知相應的客戶端
4. 集羣共享配置一致，好比數據庫鏈接的配置，業務的開關，甚至一些數據量小，不常常變的業務數據如彈窗文案，活動文案也放裏邊，用於快速迭代實現功能。

 

--命名服務

利用zookeeper的順序節點，樹形結構的數據特色，實現命名服務：

• 好比RPC框架中，每一個服務在zookeeper中對應一個節點（serviceName），節點下存放這個服務所用到的資源，好比部署的ip列表，接口列表

 

這樣RPC的客戶端只須要傳對應的服務名字，和接口，就能找到對應的服務。

• 全局惟一id的生成，UUID（通用的惟一標識碼）能夠實現，可是他的缺點是：太長，包含32位字符和4個短線字符串；看不出業務含義，不方便排查問題。

使用zookeeper實現：不一樣的業務下建立一個節點，具體的節點下用zk的順序節點(sequent)生成id當作這個業務的全局惟一id使用

--分佈式通知/協調

ZooKeeper中特有watcher註冊與異步通知機制，可以很好的實現分佈式環境下不一樣系統之間的通知與協調，實現對數據變動的實時處理。

使用方法一般是不一樣系統都對ZK上同一個znode進行註冊，監聽znode的變化（包括znode自己內容及子節點的），其中一個系統update了znode，那麼另外一個系統可以收到通知，並做出相應處理。

應用：

心跳檢測機制：傳統的方式是ping，複雜的話是創建長鏈接檢測系統和被檢測系統之間並不直接關聯起來，而是經過zookeeper上某個節點關聯，大大減小系統耦合

系統調度模式：某系統由控制檯和推送系統兩部分組成，控制檯的職責是控制推送系統進行相應的推送工做。

管理人員在控制檯做的一些操做，其實是修改了ZK上某些節點的狀態，而ZK就把這些變化通知給他們註冊Watcher的客戶端，即推送系統。因而，做出相應的推送任務

做彙報模式：一些相似於任務分發系統，子任務啓動後，到ZK來註冊一個臨時節點，而且定時將本身的進度進行彙報（將進度寫回這個臨時節點）

總之，使用zookeeper來進行分佈式通知和協調可以大大下降系統之間的耦合。

--分佈式鎖

這個應用主要得益於ZooKeeper爲咱們保證了數據的強一致性

即用戶只要徹底相信每時每刻，zk集羣中任意節點（一個zk server）上的相同znode的數據是必定是相同的。

一個節點要麼建立成功，要麼失敗，而且只由一個客戶端建立。

獨佔鎖：

保持獨佔，就是全部試圖來獲取這個鎖的客戶端，最終只有一個能夠成功得到這把鎖。

一般的作法是把ZK上的一個znode看做是一把鎖，經過create znode的方式來實現。全部客戶端都去建立/distribute_lock節點，最終成功建立的那個客戶端也即擁有了這把鎖。

共享時序控制鎖：

Zookeeper很容易實現這個功能，實現方式是須要得到鎖的Server，建立一個EPHEMERAL_SEQUENTIAL目錄節點。

而後調用getChildren方法獲取當前的目錄節點列表中最小的目錄節點是否是就是本身建立的目錄節點。

若是正是本身建立的，那麼它就得到了這個鎖，若是不是，那麼它就調用exists(String path, boolean watch)方法，並監控Zookeeper上目錄節點列表的變化，一直到本身建立的節點是列表中最小編號的目錄節點，從而得到鎖。

釋放鎖很簡單，只要刪除前面它本身所建立的目錄節點就好了。

--master選舉

 

 

master選舉應用圖

 

有個容易理解的方案，依靠關係型數據庫主鍵的特性，集羣的機器同時往一張表裏插入數據，數據庫會自動進行主鍵衝突檢查，能夠選擇插入成功的客戶端做爲master

這種方式存在一個問題就是，master機器掛了，沒有人通知

zk實現能夠方便作到這一點：zk的建立節點api接口，具備強一致性，可以保證客戶端併發建立的時候，最終必定只有一個客戶端建立成功。

• 客戶端集羣天天定時往/master_election/（當天日期）2017-03-24/binding創 建臨時節點，只有一個成功，爲master
• 建立失敗的在/master_election/（當天日期）2017-03-24 註冊監聽事件，當master掛了，其他機器收到通知，從新進行選舉

 

--集羣管理

應用舉例：集羣機器存活性監控系統，例如：

監控系統在/clusterServers節點註冊一個watcher監聽，那麼但凡進行動態添加機器的操做，就在/clusterServers下建立一個臨時節點， /clusterServers/ip。

這樣監控系統就可以實時的檢測到機器的變更，經過getChild方法獲取全部的臨時節點，來判斷增長的機器。

當有機器down調或者手動下線，相應臨時節點會消失，監控系統也會接收到，來處理監控服務的具體業務

具體服務器部署agent實現

zookeeper的HA設計實現

以上說了那麼多犀利實用的應用場景，它們依賴zookeeper，說明這些應用服務的高可用性依賴的zookeeper自己的HA。

zk的選舉算法

算法協議zab協議，「少數服從多數」協議一種

3.4.0版本以後Zookeeper只保留了TCP版本的FastLeaderElection選舉算法

分析選舉算法前，先熟悉瞭解下zk的一些術語定義解釋：

• SID：服務器ID，在集羣的配置文件裏配置
• ZXID：是一個事務ID，用來惟一標示一次服務器狀態變動，集羣中每臺機器上的ZXID可能不同
• Vote：投票選舉，當集羣中機器發現本身沒法檢測到leader的時候，開始嘗試進行投票
• Quorum：過半機器數， quorum=（集羣機器數）n/2+1，好比集羣數量是3， quorum=2

集羣數量是4，quorum=2，集羣數量是5，quorum=3

 

當哪些狀況發生時會出發leader從新選舉呢？

當zk的一臺服務器出現如下兩種狀況的時候，會進入leader選舉流程

1. 加機器，服務器初始化
2. 服務器運行期間沒法和leader通訊，leader所在服務器down掉了

 

對於第一種狀況，即已經存在一臺leader服務器，當改機器試圖去選舉leader的時候，會被告知當前服務器的leader信息，對於該機器僅僅須要和leader創建鏈接，並進行狀態同步便可

主要看下第二種狀況：

有兩種狀況致使集羣不存在leader，一個是集羣剛啓動初始化的時候，另外一種狀況是運行期間leader所在服務器掛了。

不管哪一種狀況集羣全部集羣都處在一個找leader的狀態，稱做Looking狀態，開始想其餘機器發送消息投票

開始leader選舉投票的協議規則是怎樣呢？

• 投票的消息包含（SID，ZXID）
• 一開始試圖投本身，把投票消息廣播出去
• 先比較ZXID，選擇ZXID大的
• ZXID相等的，比較SID，選擇SID大的
• 若是本身的值大於別的服務器廣播來的消息，投票不作變動
• 反正，更換投票，開始第二輪投票，廣播出去投票信息
• 每輪結束統計投票，若是一臺服務器收到超過半數的相同投票，那個這個服務器對用的SID機器爲Leader

 

 

 

5臺機器宕機兩臺後，leader選舉的過程圖示

 

所以，一個錯誤的認識，爲了使zookeeper集羣能順利的選出leader，必須將zookeeper集羣的服務器數部署爲奇數。

從上邊例子能看出來部署任意臺機器都可以正常選舉運行。部署奇數臺是官方給的建議，由於奇數和奇數+1的容災能力是同樣的。好比：

5臺服務器，可以對2臺機器掛掉的狀況進程容災

6臺服務器，可以對2臺機器掛掉的狀況進程容災，若是掛掉3臺，剩下的機器就沒法實現過半了。