5分鐘讓你了解 ZooKeeper 的功能和原理

5分鐘讓你了解 ZooKeeper 的功能和原理

一 .Zookeeper功能簡介

ZooKeeper 是一個開源的分布式協(xié)調(diào)服務，由雅虎創(chuàng)建，是 Google Chubby 的開源實現(xiàn)。

分布式應用程序可以基于 ZooKeeper 實現(xiàn)諸如數(shù)據(jù)發(fā)布/訂閱、負載均衡、命名服務、分布式協(xié)

調(diào)/通知、集群管理、Master 選舉、配置維護，名字服務、分布式同步、分布式鎖和分布式隊列

等功能。

二 . ZooKeeper基本概念

本節(jié)將介紹 ZooKeeper 的幾個核心概念

因此有必要預先了解這些概念。

集群角色

一個 ZooKeeper 集群同一時刻只會有一個 Leader，其他都是 Follower 或 Observer。

ZooKeeper 配置很簡單，每個節(jié)點的配置文件(zoo.cfg)都是一樣的，只有 myid 文件不一樣。myid 的值必須是 zoo.cfg中server.{數(shù)值} 的{數(shù)值}部分。

zoo.cfg配置文件示例

在裝有 ZooKeeper 的機器的終端執(zhí)行 zookeeper-server status 可以看當前節(jié)點的

ZooKeeper是什么角色（Leader or Follower）。

ZooKeeper 默認只有 Leader 和 Follower 兩種角色，沒有 Observer 角色。為了使用 Observer 模式，在任何想變成Observer的節(jié)點的配置文件中加入:peerType=observer 并在所有 server 的配置文件中，配置成 observer 模式的 server 的那行配置追加 :observer

2 . 節(jié)點讀寫服務分工

1.ZooKeeper 集群的所有機器通過一個 Leader 選舉過程來選定一臺被稱為『Leader』

的機器，Leader服務器為客戶端提供讀和寫服務。

2.Follower 和 Observer 都能提供讀服務，不能提供寫服務。兩者唯一的區(qū)別在于，

Observer機器不參與 Leader 選舉過程，也不參與寫操作的『過半寫成功』策略，因

此 Observer 可以在不影響寫性能的情況下提升集群的讀性能。

3 . Session

Session 是指客戶端會話，在講解客戶端會話之前，我們先來了解下客戶端連接。在

ZooKeeper 中，一個客戶端連接是指客戶端和 ZooKeeper 服務器之間的TCP長連接。

ZooKeeper 對外的服務端口默認是2181，客戶端啟動時，首先會與服務器建立一個TCP

連接，從第一次連接建立開始，客戶端會話的生命周期也開始了，通過這個連接，客戶端能夠通

過心跳檢測和服務器保持有效的會話，也能夠向 ZooKeeper 服務器發(fā)送請求并接受響應，同

時還能通過該連接接收來自服務器的 Watch 事件通知。

Session 的 SessionTimeout 值用來設置一個客戶端會話的超時時間。當由于服務器

壓力太大、網(wǎng)絡故障或是客戶端主動斷開連接等各種原因?qū)е驴蛻舳诉B接斷開時，只要在

SessionTimeout 規(guī)定的時間內(nèi)能夠重新連接上集群中任意一臺服務器，那么之前創(chuàng)建的會話

仍然有效。

4 . 數(shù)據(jù)節(jié)點

zookeeper的結(jié)構其實就是一個樹形結(jié)構，leader就相當于其中的根結(jié)點，其它節(jié)點就相當于

follow節(jié)點，每個節(jié)點都保留自己的內(nèi)容。

zookeeper的節(jié)點分兩類：持久節(jié)點和臨時節(jié)點

- 持久節(jié)點：

所謂持久節(jié)點是指一旦這個 樹形結(jié)構上被創(chuàng)建了，除非主動進行對樹節(jié)點的移除操

作，否則這個 節(jié)點將一直保存在 ZooKeeper 上。

- 臨時節(jié)點：

臨時節(jié)點的生命周期跟客戶端會話綁定，一旦客戶端會話失效，那么這個客戶端創(chuàng)

建的所有臨時節(jié)點都會被移除。

5 . 狀態(tài)信息

每個 節(jié)點除了存儲數(shù)據(jù)內(nèi)容之外，還存儲了 節(jié)點本身的一些狀態(tài)信息。用 get 命令可以

同時獲得某個 節(jié)點的內(nèi)容和狀態(tài)信息

在 ZooKeeper 中，version 屬性是用來實現(xiàn)樂觀鎖機制中的『寫入校驗』的（保證分布

式數(shù)據(jù)原子性操作）。

6 .事物操作

在ZooKeeper中，能改變ZooKeeper服務器狀態(tài)的操作稱為事務操作。一般包括數(shù)據(jù)節(jié)點

創(chuàng)建與刪除、數(shù)據(jù)內(nèi)容更新和客戶端會話創(chuàng)建與失效等操作。對應每一個事務請求，ZooKeeper

都會為其分配一個全局唯一的事務ID，用 ZXID 表示，通常是一個64位的數(shù)字。每一個 ZXID

對應一次更新操作，從這些 ZXID 中可以間接地識別出 ZooKeeper 處理這些事務操作請求的

全局順序。

7 .Watcher(事件監(jiān)聽器)

是 ZooKeeper 中一個很重要的特性。ZooKeeper允許用戶在指定節(jié)點上注冊一些 Watcher，

并且在一些特定事件觸發(fā)的時候，ZooKeeper 服務端會將事件通知到感興趣的客戶端上去。該

機制是 ZooKeeper 實現(xiàn)分布式協(xié)調(diào)服務的重要特性。

三 .ZooKeeper應用的典型場景

ZooKeeper 是一個高可用的分布式數(shù)據(jù)管理與協(xié)調(diào)框架?；趯AB算法的實現(xiàn)，該框架

能夠很好地保證分布式環(huán)境中數(shù)據(jù)的一致性。也是基于這樣的特性，使得 ZooKeeper 成為了

解決分布式一致性問題的利器。

1 . 數(shù)據(jù)發(fā)布與訂閱（配置中心）

數(shù)據(jù)發(fā)布與訂閱，即所謂的配置中心，顧名思義就是發(fā)布者將數(shù)據(jù)發(fā)布到 ZooKeeper 節(jié)點上,

供訂閱者進行數(shù)據(jù)訂閱，進而達到動態(tài)獲取數(shù)據(jù)的目的，實現(xiàn)配置信息的集中式管理和動態(tài)更新。

對于：數(shù)據(jù)量通常比較小。數(shù)據(jù)內(nèi)容在運行時動態(tài)變化。集群中各機器共享，配置一致。

這樣的全局配置信息就可以發(fā)布到 ZooKeeper上，讓客戶端（集群的機器）去訂閱該消息。

發(fā)布/訂閱系統(tǒng)一般有兩種設計模式，分別是推（Push）和拉（Pull）模式。

- 推模式

服務端主動將數(shù)據(jù)更新發(fā)送給所有訂閱的客戶端

- 拉模式

客戶端主動發(fā)起請求來獲取最新數(shù)據(jù)，通?？蛻舳硕疾捎枚〞r輪詢拉取的方式

ZooKeeper 采用的是推拉相結(jié)合的方式：

客戶端想服務端注冊自己需要關注的節(jié)點，一旦該節(jié)點的數(shù)據(jù)發(fā)生變更，那么服務端就會向相應

的客戶端發(fā)送Watcher事件通知，客戶端接收到這個消息通知后，需要主動到服務端獲取最新的數(shù)據(jù)

2 . 命名服務

命名服務也是分布式系統(tǒng)中比較常見的一類場景。在分布式系統(tǒng)中，通過使用命名服務，客戶端

應用能夠根據(jù)指定名字來獲取資源或服務的地址，提供者等信息。被命名的實體通?？梢允羌褐械?/p>

機器，提供的服務，遠程對象等等——這些我們都可以統(tǒng)稱他們?yōu)槊帧?/p>

其中較為常見的就是一些分布式服務框架（如RPC）中的服務地址列表。通過在ZooKeepr里

創(chuàng)建順序節(jié)點，能夠很容易創(chuàng)建一個全局唯一的路徑，這個路徑就可以作為一個名字。

ZooKeeper 的命名服務即生成全局唯一的ID。

3 . 分布式協(xié)調(diào)服務/通知

ZooKeeper 中特有 Watcher 注冊與異步通知機制，能夠很好的實現(xiàn)分布式環(huán)境下不同機器，

甚至不同系統(tǒng)之間的通知與協(xié)調(diào)，從而實現(xiàn)對數(shù)據(jù)變更的實時處理。使用方法通常是不同的客戶端

如果 機器節(jié)點 發(fā)生了變化，那么所有訂閱的客戶端都能夠接收到相應的Watcher通知，并做出相應

的處理。

ZooKeeper的分布式協(xié)調(diào)/通知，是一種通用的分布式系統(tǒng)機器間的通信方式。

４ . Master選舉

Master 選舉可以說是 ZooKeeper 最典型的應用場景了。比如 HDFS 中 Active NameNode 的選舉、YARN 中 Active ResourceManager 的選舉和 HBase 中 Active HMaster 的選舉等。

針對 Master 選舉的需求，通常情況下，我們可以選擇常見的關系型數(shù)據(jù)庫中的主鍵特性來

實現(xiàn)：希望成為 Master 的機器都向數(shù)據(jù)庫中插入一條相同主鍵ID的記錄，數(shù)據(jù)庫會幫我們進行

主鍵沖突檢查，也就是說，只有一臺機器能插入成功——那么，我們就認為向數(shù)據(jù)庫中成功插入數(shù)據(jù)

的客戶端機器成為Master。

依靠關系型數(shù)據(jù)庫的主鍵特性確實能夠很好地保證在集群中選舉出唯一的一個Master。

但是，如果當前選舉出的 Master 掛了，那么該如何處理？誰來告訴我 Master 掛了呢？

顯然，關系型數(shù)據(jù)庫無法通知我們這個事件。但是，ZooKeeper 可以做到！

利用 ZooKeepr 的強一致性，能夠很好地保證在分布式高并發(fā)情況下節(jié)點的創(chuàng)建一定能夠

保證全局唯一性，即 ZooKeeper 將會保證客戶端無法創(chuàng)建一個已經(jīng)存在的 數(shù)據(jù)單元節(jié)點。

也就是說，如果同時有多個客戶端請求創(chuàng)建同一個臨時節(jié)點，那么最終一定只有一個客戶端

請求能夠創(chuàng)建成功。利用這個特性，就能很容易地在分布式環(huán)境中進行 Master 選舉了。

成功創(chuàng)建該節(jié)點的客戶端所在的機器就成為了 Master。同時，其他沒有成功創(chuàng)建該節(jié)點的

客戶端，都會在該節(jié)點上注冊一個子節(jié)點變更的 Watcher，用于監(jiān)控當前 Master 機器是否存

活，一旦發(fā)現(xiàn)當前的Master掛了，那么其他客戶端將會重新進行 Master 選舉。

這樣就實現(xiàn)了 Master 的動態(tài)選舉。

５ . 分布式鎖

分布式鎖是控制分布式系統(tǒng)之間同步訪問共享資源的一種方式

分布式鎖又分為排他鎖和共享鎖兩種

排它鎖

ZooKeeper如何實現(xiàn)排它鎖？

定義鎖

ZooKeeper 上的一個 機器節(jié)點 可以表示一個鎖

獲得鎖

把ZooKeeper上的一個節(jié)點看作是一個鎖，獲得鎖就通過創(chuàng)建臨時節(jié)點的方式來實現(xiàn)。

ZooKeeper 會保證在所有客戶端中，最終只有一個客戶端能夠創(chuàng)建成功，那么就可以

認為該客戶端獲得了鎖。同時，所有沒有獲取到鎖的客戶端就需要到/exclusive_lock

節(jié)點上注冊一個子節(jié)點變更的Watcher監(jiān)聽，以便實時監(jiān)聽到lock節(jié)點的變更情況。

釋放鎖

因為鎖是一個臨時節(jié)點，釋放鎖有兩種方式

當前獲得鎖的客戶端機器發(fā)生宕機或重啟，那么該臨時節(jié)點就會被刪除，釋放鎖

正常執(zhí)行完業(yè)務邏輯后，客戶端就會主動將自己創(chuàng)建的臨時節(jié)點刪除，釋放鎖。

無論在什么情況下移除了lock節(jié)點，ZooKeeper 都會通知所有在 /exclusive_lock 節(jié)點上注冊了節(jié)點變更 Watcher 監(jiān)聽的客戶端。這些客戶端在接收到通知后，再次重新發(fā)起分布式鎖獲取，即重復『獲取鎖』過程。

共享鎖

共享鎖在同一個進程中很容易實現(xiàn)，但是在跨進程或者在不同 Server 之間就不好實現(xiàn)了。Zookeeper 卻很容易實現(xiàn)這個功能，實現(xiàn)方式也是需要獲得鎖的 Server 創(chuàng)建一個 EPHEMERAL_SEQUENTIAL 目錄節(jié)點，然后調(diào)用 getChildren方法獲取當前的目錄節(jié)點列表中最小的目錄節(jié)點是不是就是自己創(chuàng)建的目錄節(jié)點，如果正是自己創(chuàng)建的，那么它就獲得了這個鎖，如果不是那么它就調(diào)用 exists(String path, boolean watch) 方法并監(jiān)控 Zookeeper 上目錄節(jié)點列表的變化，一直到自己創(chuàng)建的節(jié)點是列表中最小編號的目錄節(jié)點，從而獲得鎖，釋放鎖很簡單，只要刪除前面它自己所創(chuàng)建的目錄節(jié)點就行了。

總結(jié)

本文介紹的 Zookeeper 的基本知識，以及介紹了幾個典型的應用場景。這些都是 Zookeeper

的基本功能，最重要的是 Zoopkeeper 提供了一套很好的分布式集群管理的機制，就是它這種基于

層次型的目錄樹的數(shù)據(jù)結(jié)構，并對樹中的節(jié)點進行有效管理，從而可以設計出多種多樣的分布式的數(shù)

據(jù)管理模型，而不僅僅局限于上面提到的幾個常用應用場景

喜歡這篇文章的話記得給我點個關注哦，每天都會分享java有關的文章