雲栖号資訊：【 點選檢視更多行業資訊】
在這裡您可以找到不同行業的第一手的上雲資訊，還在等什麼，快來！
什麼是 ZooKeeper
ZooKeeper 是 Apache 的一個頂級項目，為分布式應用提供高效、高可用的分布式協調服務，提供了諸如資料釋出/訂閱、負載均衡、命名服務、分布式協調/通知和分布式鎖等分布式基礎服務。由于 ZooKeeper 便捷的使用方式、卓越的性能和良好的穩定性，被廣泛地應用于諸如 Hadoop、HBase、Kafka 和 Dubbo 等大型分布式系統中。
ZooKeeper 有三種運作模式：單機模式、僞叢集模式和叢集模式。
- 單機模式：這種模式一般适用于開發測試環境，一方面我們沒有那麼多機器資源，另外就是平時的開發調試并不需要極好的穩定性。
- 叢集模式：一個 ZooKeeper 叢集通常由一組機器組成，一般 3 台以上就可以組成一個可用的 ZooKeeper 叢集了。組成 ZooKeeper 叢集的每台機器都會在記憶體中維護目前的伺服器狀态，并且每台機器之間都會互相保持通信。
- 僞叢集模式：這是一種特殊的叢集模式，即叢集的所有伺服器都部署在一台機器上。當你手頭上有一台比較好的機器，如果作為單機模式進行部署，就會浪費資源，這種情況下，ZooKeeper允許你在一台機器上通過啟動不同的端口來啟動多個 ZooKeeper 服務執行個體，以此來以叢集的特性來對外服務。
ZooKeeper 的相關知識
ZooKeeper 中的角色
- 上司者（leader）：負責進行投票的發起和決議，更新系統狀态
- 跟随者（follower）：用于接收用戶端請求并給用戶端傳回結果，在選主過程中進行投票
- 觀察者（observer）：可以接受用戶端連接配接，将寫請求轉發給 leader，但是observer不參加投票的過程，隻是為了擴充系統，提高讀取的速度。
ZooKeeper 的資料模型
- 階層化的目錄結構，命名符合正常檔案系統規範，類似于 Linux
- 每個節點在 ZooKeeper 中叫做 Znode，并且其有一個唯一的路徑辨別
- 節點 Znode 可以包含資料和子節點，但是 EPHEMERAL 類型的節點不能有子節點
- Znode 中的資料可以有多個版本，比如某一個路徑下存有多個資料版本，那麼查詢這個路徑下的資料就需要帶上版本
- 用戶端應用可以在節點上設定螢幕
- 節點不支援部分讀寫，而是一次性完整讀寫
ZooKeeper 的節點特性
ZooKeeper 節點是生命周期的，這取決于節點的類型。在 ZooKeeper 中，節點根據持續時間可以分為持久節點（PERSISTENT）、臨時節點（EPHEMERAL），根據是否有序可以分為順序節點（SEQUENTIAL）、和無序節點（預設是無序的）。
持久節點一旦被建立，除非主動移除，不然一直會儲存在 ZooKeeper 中（不會因為建立該節點的用戶端的會話失效而消失），臨時節點。
ZooKeeper 的應用場景
ZooKeeper 是一個高可用的分布式資料管理與系統協調架構。基于對 Paxos 算法的實作，使該架構保證了分布式環境中資料的強一緻性，也正是基于這樣的特性，使得 ZooKeeper 解決很多分布式問題。
值得注意的是，ZooKeeper 并非天生就是為這些應用場景設計的，都是後來衆多開發者根據其架構的特性，利用其提供的一系列 API 接口（或者稱為原語集），摸索出來的典型使用方法。
資料釋出與訂閱（配置中心）
釋出與訂閱模型，即所謂的配置中心，顧名思義就是釋出者将資料釋出到 ZooKeeper 節點上，供訂閱者動态擷取資料，實作配置資訊的集中式管理和動态更新。例如全局的配置資訊，服務式服務架構的服務位址清單等就非常适合使用。
應用中用到的一些配置資訊放到ZK上進行集中管理。這類場景通常是這樣：應用在啟動的時候會主動來擷取一次配置，同時，在節點上注冊一個 Watcher，這樣一來，以後每次配置有更新的時候，都會實時通知到訂閱的用戶端，從來達到擷取最新配置資訊的目的。 分布式搜尋服務中，索引的元資訊和伺服器叢集機器的節點狀态存放在 ZooKeeper 的一些指定節點，供各個用戶端訂閱使用。分布式日志收集系統。這個系統的核心工作是收集分布在不同機器的日志。收集器通常是按照應用來配置設定收集任務單元，是以需要在 ZooKeeper 上建立一個以應用名作為 path 的節點 P，并将這個應用的所有機器 IP，以子節點的形式注冊到節點 P 上，這樣一來就能夠實作機器變動的時候，能夠實時通知到收集器調整任務配置設定。 系統中有些資訊需要動态擷取，并且還會存在人工手動去修改這個資訊的發問。通常是暴露出接口，例如 JMX 接口，來擷取一些運作時的資訊。引入 ZooKeeper 之後，就不用自己實作一套方案了，隻要将這些資訊存放到指定的 ZooKeeper 節點上即可。 注意：在上面提到的應用場景中，有個預設前提是：資料量很小，但是資料更新可能會比較快的場景。
負載均衡
這裡說的負載均衡是指軟負載均衡。在分布式環境中，為了保證高可用性，通常同一個應用或同一個服務的提供方都會部署多份，達到對等服務。而消費者就須要在這些對等的伺服器中選擇一個來執行相關的業務邏輯，其中比較典型的是消息中間件中的生産者，消費者負載均衡。
命名服務（Naming Service）
命名服務也是分布式系統中比較常見的一類場景。在分布式系統中，通過使用命名服務，用戶端應用能夠根據指定名字來擷取資源或服務的位址，提供者等資訊。被命名的實體通常可以是叢集中的機器，提供的服務位址，遠端對象等等——這些我們都可以統稱他們為名字（Name）。其中較為常見的就是一些分布式服務架構中的服務位址清單。通過調用ZK提供的建立節點的API，能夠很容易建立一個全局唯一的 path，這個 path就可以作為一個名稱。
阿裡巴巴集團開源的分布式服務架構 Dubbo 中使用 ZooKeeper 來作為其命名服務，維護全局的服務位址清單。在 Dubbo 實作中： 服務提供者在啟動的時候，向 ZooKeeper 上的指定節點 /dubbo/${serviceName}/providers 目錄下寫入自己的 URL 位址，這個操作就完成了服務的釋出。 服務消費者啟動的時候，訂閱 /dubbo/${serviceName}/providers 目錄下的提供者 URL 位址， 并向 /dubbo/${serviceName} /consumers 目錄下寫入自己的 URL 位址。 注意，所有向 ZooKeeper 上注冊的位址都是臨時節點，這樣就能夠保證服務提供者和消費者能夠自動感應資源的變化。
另外，Dubbo 還有針對服務粒度的監控，方法是訂閱 /dubbo/${serviceName} 目錄下所有提供者和消費者的資訊。
分布式通知/協調
ZooKeeper 中特有 watcher 注冊與異步通知機制，能夠很好的實作分布式環境下不同系統之間的通知與協調，實作對資料變更的實時處理。使用方法通常是不同系統都對 ZooKeeper 上同一個 Znode 進行注冊，監聽 Znode 的變化（包括 Znode 本身内容及子節點的），其中一個系統 update 了 Znode，那麼另一個系統能夠收到通知，并作出相應處理。
另一種心跳檢測機制：檢測系統和被檢測系統之間并不直接關聯起來，而是通過zk上某個節點關聯，大大減少系統耦合。 另一種系統排程模式：某系統有控制台和推送系統兩部分組成，控制台的職責是控制推送系統進行相應的推送工作。管理人員在控制台作的一些操作，實際上是修改了 ZooKeeper 上某些節點的狀态，而 ZooKeeper 就把這些變化通知給他們注冊 Watcher 的用戶端，即推送系統，于是，作出相應的推送任務。
另一種工作彙報模式：一些類似于任務分發系統，子任務啟動後，到 ZooKeeper 來注冊一個臨時節點，并且定時将自己的進度進行彙報（将進度寫回這個臨時節點），這樣任務管理者就能夠實時知道任務進度。
分布式鎖
分布式鎖，這個主要得益于 ZooKeeper 為我們保證了資料的強一緻性。鎖服務可以分為兩類，一個是保持獨占，另一個是控制時序。
所謂保持獨占，就是所有試圖來擷取這個鎖的用戶端，最終隻有一個可以成功獲得這把鎖。通常的做法是把 ZooKeeper 上的一個 Znode 看作是一把鎖，通過 create znode 的方式來實作。所有用戶端都去建立 /distribute_lock 節點，最終成功建立的那個用戶端也即擁有了這把鎖。控制時序，就是所有視圖來擷取這個鎖的用戶端，最終都是會被安排執行，隻是有個全局時序了。做法和上面基本類似，隻是這裡 /distribute_lock 已經預先存在，用戶端在它下面建立臨時有序節點（這個可以通過節點的屬性控制：CreateMode.EPHEMERAL_SEQUENTIAL 來指定）。
ZooKeeper 的父節點（/distribute_lock）維持一份 sequence，保證子節點建立的時序性，進而也形成了每個用戶端的全局時序。
由于同一節點下子節點名稱不能相同，是以隻要在某個節點下建立 Znode，建立成功即表明加鎖成功。注冊監聽器監聽此 Znode，隻要删除此 Znode 就通知其他用戶端來加鎖。
建立臨時順序節點：在某個節點下建立節點，來一個請求則建立一個節點，由于是順序的，是以序号最小的獲得鎖，當釋放鎖時，通知下一序号獲得鎖。
分布式隊列
隊列方面，簡單來說有兩種，一種是正常的先進先出隊列，另一種是等隊列的隊員聚齊以後才按照順序執行。對于第一種的隊列和上面講的分布式鎖服務中控制時序的場景基本原理一緻，這裡就不贅述了。
第二種隊列其實是在 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 檔案内容如下：
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 下載下傳下來。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 就能進行連接配接了。
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 /
建立了一個新的 Znode 節點“ zk ”以及與它關聯的字元串。
指令：create /zk myData
擷取 Znode 節點 zk。
指令：get /zk
删除 Znode 節點 zk。
指令：delete /zk
【雲栖号線上課堂】每天都有産品技術專家分享！
課程位址：
https://yqh.aliyun.com/live立即加入社群，與專家面對面，及時了解課程最新動态！
【雲栖号線上課堂 社群】
https://c.tb.cn/F3.Z8gvnK
原文釋出時間：2020-06-03
本文作者：大衛
本文來自：“
dockone”，了解相關資訊可以關注“dockone”