Zookeeper什麼，它能夠作什麼？看了這篇就懂了

前言

什麼是ZooKeeper，你真的瞭解它嗎。咱們一塊兒來看看吧~

什麼是 ZooKeeper

ZooKeeper 是 Apache 的一個頂級項目，爲分佈式應用提供高效、高可用的分佈式協調服務，提供了諸如數據發佈/訂閱、負載均衡、命名服務、分佈式協調/通知和分佈式鎖等分佈式基礎服務。因爲 ZooKeeper 便捷的使用方式、卓越的性能和良好的穩定性，被普遍地應用於諸如 Hadoop、HBase、Kafka 和 Dubbo 等大型分佈式系統中。

Zookeeper 有三種運行模式：單機模式、僞集羣模式和集羣模式。

單機模式：
這種模式通常適用於開發測試環境，一方面咱們沒有那麼多機器資源，另外就是平時的開發調試並不須要極好的穩定性。

集羣模式：
一個 ZooKeeper 集羣一般由一組機器組成，通常 3 臺以上就能夠組成一個可用的 ZooKeeper 集羣了。組成 ZooKeeper 集羣的每臺機器都會在內存中維護當前的服務器狀態，而且每臺機器之間都會互相保持通訊。

僞集羣模式：
這是一種特殊的集羣模式，即集羣的全部服務器都部署在一臺機器上。當你手頭上有一臺比較好的機器，若是做爲單機模式進行部署，就會浪費資源，這種狀況下，ZooKeeper 容許你在一臺機器上經過啓動不一樣的端口來啓動多個 ZooKeeper 服務實例，以此來以集羣的特性來對外服務。

ZooKeeper 的相關知識

Zookeeper 中的角色：

領導者（leader）：
負責進行投票的發起和決議，更新系統狀態。

跟隨者（follower）：
用於接收客戶端請求並給客戶端返回結果，在選主過程當中進行投票。

觀察者（observer）：
能夠接受客戶端鏈接，將寫請求轉發給 leader，可是observer 不參加投票的過程，只是爲了擴展系統，提升讀取的速度。

Zookeeper 的數據模型

1.層次化的目錄結構，命名符合常規文件系統規範，相似於 Linux。

2.每一個節點在 Zookeeper 中叫作 Znode，而且其有一個惟一的路徑標識。

3.節點 Znode 能夠包含數據和子節點，可是 EPHEMERAL 類型的節點不能有子節點。

4.Znode 中的數據能夠有多個版本，好比某一個路徑下存有多個數據版本，那麼查詢這個路徑下的數據就須要帶上版本。

5.客戶端應用能夠在節點上設置監視器。

6.節點不支持部分讀寫，而是一次性完整讀寫。

ZooKeeper 的節點特性

ZooKeeper 節點是生命週期的，這取決於節點的類型。在 ZooKeeper 中，節點根據持續時間能夠分爲持久節點（PERSISTENT）、臨時節點（EPHEMERAL），根據是否有序能夠分爲順序節點（SEQUENTIAL）、和無序節點（默認是無序的）。

持久節點一旦被建立，除非主動移除，否則一直會保存在 Zookeeper 中（不會由於建立該節點的客戶端的會話失效而消失）。

Zookeeper 的應用場景

ZooKeeper 是一個高可用的分佈式數據管理與系統協調框架。基於對 Paxos 算法的實現，使該框架保證了分佈式環境中數據的強一致性，也正是基於這樣的特性，使得 ZooKeeper 解決不少分佈式問題。

值得注意的是，ZooKeeper 並不是天生就是爲這些應用場景設計的，都是後來衆多開發者根據其框架的特性，利用其提供的一系列 API 接口（或者稱爲原語集），摸索出來的典型使用方法。

數據發佈與訂閱（配置中心）

發佈與訂閱模型，即所謂的配置中心，顧名思義就是發佈者將數據發佈到 ZooKeeper 節點上，供訂閱者動態獲取數據，實現配置信息的集中式管理和動態更新。例如全局的配置信息，服務式服務框架的服務地址列表等就很是適合使用。

應用中用到的一些配置信息放到 ZooKeeper 上進行集中管理。這類場景一般是這樣：應用在啓動的時候會主動來獲取一次配置，同時在節點上註冊一個 Watcher。這樣一來，之後每次配置有更新的時候，都會實時通知到訂閱的客戶端，歷來達到獲取最新配置信息的目的。

分佈式搜索服務中，索引的元信息和服務器集羣機器的節點狀態存放在 ZooKeeper 的一些指定節點，供各個客戶端訂閱使用。

分佈式日誌收集系統

這個系統的核心工做是收集分佈在不一樣機器的日誌。收集器一般是按照應用來分配收集任務單元，所以須要在 ZooKeeper 上建立一個以應用名做爲 path 的節點 P，並將這個應用的全部機器 IP，以子節點的形式註冊到節點 P 上。這樣一來就可以實現機器變更的時候，可以實時通知到收集器調整任務分配。

系統中有些信息須要動態獲取，而且還會存在人工手動去修改這個信息的發問。一般是暴露出接口，例如 JMX 接口，來獲取一些運行時的信息。引入 ZooKeeper 以後，就不用本身實現一套方案了，只要將這些信息存放到指定的 ZooKeeper 節點上便可。

注意：
在上面提到的應用場景中，有個默認前提——數據量很小，可是數據更新可能會比較快的場景。

負載均衡

這裏說的負載均衡是指軟負載均衡。在分佈式環境中，爲了保證高可用性，一般同一個應用或同一個服務的提供方都會部署多份，達到對等服務。而消費者就需要在這些對等的服務器中選擇一個來執行相關的業務邏輯，其中比較典型的是消息中間件中的生產者，消費者負載均衡。

命名服務（Naming Service）

命名服務也是分佈式系統中比較常見的一類場景。在分佈式系統中，經過使用命名服務，客戶端應用可以根據指定名字來獲取資源或服務的地址，提供者等信息。被命名的實體一般能夠是集羣中的機器，提供的服務地址，遠程對象等等——這些咱們均可以統稱它們爲名字（Name）。其中較爲常見的就是一些分佈式服務框架中的服務地址列表。經過調用 ZooKeeper 提供的建立節點的 API，可以很容易建立一個全局惟一的path，這個 path 就能夠做爲一個名字。

阿里巴巴集團開源的分佈式服務框架 Dubbo 中使用 ZooKeeper 來做爲其命名服務，維護全局的服務地址列表。在 Dubbo 的實現中：

1.服務提供者在啓動的時候，向 ZooKeeper 上的指定節點 /dubbo/${serviceName}/providers 目錄下寫入本身的 URL 地址，這個操做就完成了服務的發佈。

2.服務消費者啓動的時候，訂閱 /dubbo/${serviceName}/providers 目錄下的提供者 URL 地址， 並向 /dubbo/${serviceName} /consumers 目錄下寫入本身的 URL 地址。

注意：
全部向 ZooKeeper 上註冊的地址都是臨時節點，這樣就可以保證服務提供者和消費者可以自動感應資源的變化。

另外，Dubbo 還有針對服務粒度的監控。方法是訂閱 /dubbo/${serviceName} 目錄下全部提供者和消費者的信息。

分佈式通知/協調

ZooKeeper 中特有 Watcher 註冊與異步通知機制，可以很好的實現分佈式環境下不一樣系統之間的通知與協調，實現對數據變動的實時處理。使用方法一般是不一樣系統都對 ZooKeeper 上同一個 Znode 進行註冊，監聽 Znode 的變化（包括 Znode 自己內容及子節點的），其中一個系統 Update 了 Znode，那麼另外一個系統可以收到通知，並做出相應處理。

另外一種心跳檢測機制：檢測系統和被檢測系統之間並不直接關聯起來，而是經過 ZooKeeper 上某個節點關聯，大大減小系統耦合。

另外一種系統調度模式：某系統有控制檯和推送系統兩部分組成，控制檯的職責是控制推送系統進行相應的推送工做。管理人員在控制檯做的一些操做，其實是修改了 ZooKeeper 上某些節點的狀態，而 ZooKeeper 就把這些變化通知給它們註冊 Watcher 的客戶端，即推送系統。因而，做出相應的推送任務。

另外一種工做彙報模式：一些相似於任務分發系統。子任務啓動後，到 ZooKeeper 來註冊一個臨時節點，而且定時將本身的進度進行彙報（將進度寫回這個臨時節點）。這樣任務管理者就可以實時知道任務進度。

分佈式鎖

分佈式鎖主要得益於 ZooKeeper 爲咱們保證了數據的強一致性。鎖服務能夠分爲兩類：一類是保持獨佔，另外一類是控制時序。

所謂保持獨佔，就是全部試圖來獲取這個鎖的客戶端，最終只有一個能夠成功得到這把鎖。一般的作法是把 ZooKeeper 上的一個 Znode 看做是一把鎖，經過 create znode的方式來實現。全部客戶端都去建立 /distribute_lock 節點，最終成功建立的那個客戶端也即擁有了這把鎖。

控制時序，就是全部視圖來獲取這個鎖的客戶端，最終都是會被安排執行，只是有個全局時序了。作法和上面基本相似，只是這裏 /distribute_lock 已經預先存在，客戶端在它下面建立臨時有序節點（這個能夠經過節點的屬性控制：CreateMode.EPHEMERAL_SEQUENTIAL 來指定）。ZooKeeper 的父節點（/distribute_lock）維持一份 sequence，保證子節點建立的時序性，從而也造成了每一個客戶端的全局時序。

1.因爲同一節點下子節點名稱不能相同，因此只要在某個節點下建立 Znode，建立成功即代表加鎖成功。註冊監聽器監聽此 Znode，只要刪除此 Znode 就通知其餘客戶端來加鎖。

2.建立臨時順序節點：在某個節點下建立節點，來一個請求則建立一個節點，因爲是順序的，因此序號最小的得到鎖，當釋放鎖時，通知下一序號得到鎖。

分佈式隊列

隊列方面，簡單來講有兩種：一種是常規的先進先出隊列，另外一種是等隊列的隊員聚齊之後才按照順序執行。對於第一種的隊列和上面講的分佈式鎖服務中控制時序的場景基本原理一致，這裏就不贅述了。

第二種隊列實際上是在 FIFO 隊列的基礎上做了一個加強。一般能夠在 /queue 這個 Znode 下預先創建一個 /queue/num 節點，而且賦值爲 n（或者直接給 /queue 賦值 n）表示隊列大小。以後每次有隊列成員加入後，就判斷下是否已經到達隊列大小，決定是否能夠開始執行了。

這種用法的典型場景是：分佈式環境中，一個大任務 Task A，須要在不少子任務完成（或條件就緒）狀況下才能進行。這個時候，凡是其中一個子任務完成（就緒），那麼就去 /taskList 下創建本身的臨時時序節點（CreateMode.EPHEMERAL_SEQUENTIAL）。當 /taskList 發現本身下面的子節點知足指定個數，就能夠進行下一步按序進行處理了。

使用 dokcer-compose 搭建集羣

上面咱們介紹了關於 ZooKeeper 有這麼多的應用場景，那麼接下來就先學習如何搭建 ZooKeeper 集羣而後再進行實戰上面的應用場景。

文件的目錄結構以下：

├── docker-compose.yml

編寫 docker-compose.yml 文件

docker-compose.yml 文件內容以下：

version: '3.4'

services:
  zoo1:
    image: zookeeper
    restart: always
    hostname: zoo1
    ports:
      - 2181:2181
    environment:
      ZOO_MY_ID: 1
      ZOO_SERVERS: server.1=0.0.0.0:2888:3888;2181 server.2=zoo2:2888:3888;2181 server.3=zoo3:2888:3888;2181

  zoo2:
    image: zookeeper
    restart: always
    hostname: zoo2
    ports:
      - 2182:2181
    environment:
      ZOO_MY_ID: 2
      ZOO_SERVERS: server.1=zoo1:2888:3888;2181 server.2=0.0.0.0:2888:3888;2181 server.3=zoo3:2888:3888;2181

  zoo3:
    image: zookeeper
    restart: always
    hostname: zoo3
    ports:
      - 2183:2181
    environment:
      ZOO_MY_ID: 3
      ZOO_SERVERS: server.1=zoo1:2888:3888;2181 server.2=zoo2:2888:3888;2181 server.3=0.0.0.0:2888:3888;2181

在這個配置文件中，Docker 運行了 3 個 Zookeeper 鏡像，經過 ports 字段分別將本地的 2181, 2182, 2183 端口綁定到對應容器的 2181 端口上。

ZOO_MY_ID 和 ZOO_SERVERS 是搭建 Zookeeper 集羣須要的兩個環境變量。ZOO_MY_ID 標識服務的 id，爲 1-255 之間的整數，必須在集羣中惟一。ZOO_SERVERS 是集羣中的主機列表。

在 docker-compose.yml 所在目錄下執行 docker-compose up，能夠看到啓動的日誌。

鏈接 ZooKeeper

將集羣啓動起來之後咱們能夠鏈接 ZooKeeper 對其進行節點的相關操做。

1.首先須要下載 ZooKeeper。

2.將其解壓。

3.進入其 conf/ 目錄，將 zoo_sample .cfg 改爲 zoo.cfg。

配置文件說明

# The number of milliseconds of each tick
# tickTime：CS通訊心跳數
# Zookeeper 服務器之間或客戶端與服務器之間維持心跳的時間間隔，也就是每一個 tickTime 時間就會發送一個心跳。tickTime以毫秒爲單位。
tickTime=2000

# The number of ticks that the initial
# synchronization phase can take
# initLimit：LF初始通訊時限
# 集羣中的follower服務器(F)與leader服務器(L)之間初始鏈接時能容忍的最多心跳數（tickTime的數量）。
initLimit=5

# The number of ticks that can pass between
# sending a request and getting an acknowledgement
# syncLimit：LF同步通訊時限
# 集羣中的follower服務器與leader服務器之間請求和應答之間能容忍的最多心跳數（tickTime的數量）。
syncLimit=2

# the directory where the snapshot is stored.
# do not use /tmp for storage, /tmp here is just
# example sakes.
# dataDir：數據文件目錄
# Zookeeper保存數據的目錄，默認狀況下，Zookeeper將寫數據的日誌文件也保存在這個目錄裏。
dataDir=/data/soft/zookeeper-3.4.12/data

# dataLogDir：日誌文件目錄
# Zookeeper保存日誌文件的目錄。
dataLogDir=/data/soft/zookeeper-3.4.12/logs

# the port at which the clients will connect
# clientPort：客戶端鏈接端口
# 客戶端鏈接 Zookeeper 服務器的端口，Zookeeper 會監聽這個端口，接受客戶端的訪問請求。
clientPort=2181
# the maximum number of client connections.
# increase this if you need to handle more clients
#maxClientCnxns=60
#
# Be sure to read the maintenance section of the
# administrator guide before turning on autopurge.
#
# http://zookeeper.apache.org/doc/current/zookeeperAdmin.html#sc_maintenance
#
# The number of snapshots to retain in dataDir
#autopurge.snapRetainCount=3
# Purge task interval in hours
# Set to "0" to disable auto purge feature
#autopurge.purgeInterval=1


# 服務器名稱與地址：集羣信息（服務器編號，服務器地址，LF通訊端口，選舉端口）
# 這個配置項的書寫格式比較特殊，規則以下：
# server.N=YYY:A:B
# 其中N表示服務器編號，YYY表示服務器的IP地址，A爲LF通訊端口，表示該服務器與集羣中的leader交換的信息的端口。B爲選舉端口，表示選舉新leader時服務器間相互通訊的端口（當leader掛掉時，其他服務器會相互通訊，選擇出新的leader）。通常來講，集羣中每一個服務器的A端口都是同樣，每一個服務器的B端口也是同樣。可是當所採用的爲僞集羣時，IP地址都同樣，只能時A端口和B端口不同。

能夠不修改 zoo.cfg，使用默認配置。接下來在解壓後的 bin/ 目錄中執行命令 ./zkCli.sh -server 127.0.0.1:2181 就能進行鏈接了。

Welcome to ZooKeeper!
2020-06-01 15:03:52,512 [myid:] - INFO  [main-SendThread(localhost:2181):ClientCnxn$SendThread@1025] - Opening socket connection to server localhost/127.0.0.1:2181. Will not attempt to authenticate using SASL (unknown error)
JLine support is enabled
2020-06-01 15:03:52,576 [myid:] - INFO  [main-SendThread(localhost:2181):ClientCnxn$SendThread@879] - Socket connection established to localhost/127.0.0.1:2181, initiating session
2020-06-01 15:03:52,599 [myid:] - INFO  [main-SendThread(localhost:2181):ClientCnxn$SendThread@1299] - Session establishment complete on server localhost/127.0.0.1:2181, sessionid = 0x100001140080000, negotiated timeout = 30000
WATCHER::

WatchedEvent state:SyncConnected type:None path:null
[zk: 127.0.0.1:2181(CONNECTED) 0]

接下來可使用命令查看節點：

使用 ls 命令查看當前 ZooKeeper 中所包含的內容。命令：ls /

[zk: 127.0.0.1:2181(CONNECTED) 10] ls /
[zookeeper]

建立了一個新的 znode 節點 zk 以及與它關聯的字符串。命令：create /zk myData

[zk: 127.0.0.1:2181(CONNECTED) 11] create /zk myData
Created /zk
[zk: 127.0.0.1:2181(CONNECTED) 12] ls /
[zk, zookeeper]
[zk: 127.0.0.1:2181(CONNECTED) 13]

獲取 znode 節點 zk。命令：get /zk

[zk: 127.0.0.1:2181(CONNECTED) 13] get /zk
myData
cZxid = 0x400000008
ctime = Mon Jun 01 15:07:50 CST 2020
mZxid = 0x400000008
mtime = Mon Jun 01 15:07:50 CST 2020
pZxid = 0x400000008
cversion = 0
dataVersion = 0
aclVersion = 0
ephemeralOwner = 0x0
dataLength = 6
numChildren = 0

刪除 znode 節點 zk。命令：delete /zk

[zk: 127.0.0.1:2181(CONNECTED) 14] delete /zk
[zk: 127.0.0.1:2181(CONNECTED) 15] ls /
[zookeeper]

因爲篇幅有限，在接下來的文章中會根據上面提到的 ZooKeeper 應用場景逐一進行用代碼進行實現。

你們能夠直接從 GitHub 拉取項目，啓動只須要兩步：

1.從 GitHub 上面拉取項目。

2.在 ZooKeeper 文件夾中執行 docker-compose up 命令。

最後

我這邊整理了一份：Zookeeper相關資料，Java核心知識點（包括Spring全家桶系列、面試專題和20年最新的互聯網真題、電子書等）有須要的朋友能夠關注公衆號【程序媛小琬】便可獲取。