什么是 ZooKeeper

ZooKeeper 是 Apache 的一個頂級項目，為分布式應(yīng)用提供高效、高可用的分布式協(xié)調(diào)服務(wù)，提供了諸如數(shù)據(jù)發(fā)布/訂閱、負載均衡、命名服務(wù)、分布式協(xié)調(diào)/通知和分布式鎖等分布式基礎(chǔ)服務(wù)。由于 ZooKeeper 便捷的使用方式、卓越的性能和良好的穩(wěn)定性，被廣泛地應(yīng)用于諸如 Hadoop、HBase、Kafka 和 Dubbo 等大型分布式系統(tǒng)中。

Zookeeper 有三種運行模式：單機模式、偽集群模式和集群模式。

• 單機模式：這種模式一般適用于開發(fā)測試環(huán)境，一方面我們沒有那么多機器資源，另外就是平時的開發(fā)調(diào)試并不需要極好的穩(wěn)定性。
• 集群模式：一個 ZooKeeper 集群通常由一組機器組成，一般 3 臺以上就可以組成一個可用的 ZooKeeper 集群了。組成 ZooKeeper 集群的每臺機器都會在內(nèi)存中維護當(dāng)前的服務(wù)器狀態(tài)，并且每臺機器之間都會互相保持通信。
• 偽集群模式：這是一種特殊的集群模式，即集群的所有服務(wù)器都部署在一臺機器上。當(dāng)你手頭上有一臺比較好的機器，如果作為單機模式進行部署，就會浪費資源，這種情況下，ZooKeeper允許你在一臺機器上通過啟動不同的端口來啟動多個 ZooKeeper 服務(wù)實例，以此來以集群的特性來對外服務(wù)。

ZooKeeper 的相關(guān)知識

• Zookeeper 中的角色領(lǐng)導(dǎo)者（leader）：負責(zé)進行投票的發(fā)起和決議，更新系統(tǒng)狀態(tài)
• 跟隨者（follower）：用于接收客戶端請求并給客戶端返回結(jié)果，在選主過程中進行投票
• 觀察者（observer）：可以接受客戶端連接，將寫請求轉(zhuǎn)發(fā)給 leader，但是observer不參加投票的過程，只是為了擴展系統(tǒng)，提高讀取的速度。

Zookeeper 的數(shù)據(jù)模型

• 層次化的目錄結(jié)構(gòu)，命名符合常規(guī)文件系統(tǒng)規(guī)范，類似于Linux
• 每個節(jié)點在zookeeper中叫做znode,并且其有一個唯一的路徑標(biāo)識
• 節(jié)點Znode可以包含數(shù)據(jù)和子節(jié)點，但是EPHEMERAL類型的節(jié)點不能有子節(jié)點
• Znode中的數(shù)據(jù)可以有多個版本，比如某一個路徑下存有多個數(shù)據(jù)版本，那么查詢這個路徑下的數(shù)據(jù)就需要帶上版本
• 客戶端應(yīng)用可以在節(jié)點上設(shè)置監(jiān)視器
• 節(jié)點不支持部分讀寫，而是一次性完整讀寫

ZooKeeper 的節(jié)點特性

ZooKeeper 節(jié)點是生命周期的，這取決于節(jié)點的類型。在 ZooKeeper 中，節(jié)點根據(jù)持續(xù)時間可以分為持久節(jié)點（PERSISTENT）、臨時節(jié)點（EPHEMERAL），根據(jù)是否有序可以分為順序節(jié)點（SEQUENTIAL）、和無序節(jié)點（默認(rèn)是無序的）。

持久節(jié)點一旦被創(chuàng)建，除非主動移除，不然一直會保存在Zookeeper中（不會因為創(chuàng)建該節(jié)點的客戶端的會話失效而消失），臨時節(jié)點

Zookeeper 的應(yīng)用場景

ZooKeeper 是一個高可用的分布式數(shù)據(jù)管理與系統(tǒng)協(xié)調(diào)框架。基于對 Paxos 算法的實現(xiàn)，使該框架保證了分布式環(huán)境中數(shù)據(jù)的強一致性，也正是基于這樣的特性，使得 ZooKeeper 解決很多分布式問題。

值得注意的是，ZooKeeper 并非天生就是為這些應(yīng)用場景設(shè)計的，都是后來眾多開發(fā)者根據(jù)其框架的特性，利用其提供的一系列API接口（或者稱為原語集），摸索出來的典型使用方法。

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

發(fā)布與訂閱模型，即所謂的配置中心，顧名思義就是發(fā)布者將數(shù)據(jù)發(fā)布到ZK節(jié)點上，供訂閱者動態(tài)獲取數(shù)據(jù)，實現(xiàn)配置信息的集中式管理和動態(tài)更新。例如全局的配置信息，服務(wù)式服務(wù)框架的服務(wù)地址列表等就非常適合使用。

應(yīng)用中用到的一些配置信息放到ZK上進行集中管理。這類場景通常是這樣：應(yīng)用在啟動的時候會主動來獲取一次配置，同時，在節(jié)點上注冊一個Watcher，這樣一來，以后每次配置有更新的時候，都會實時通知到訂閱的客戶端，從來達到獲取最新配置信息的目的。 分布式搜索服務(wù)中，索引的元信息和服務(wù)器集群機器的節(jié)點狀態(tài)存放在ZK的一些指定節(jié)點，供各個客戶端訂閱使用。 分布式日志收集系統(tǒng)。這個系統(tǒng)的核心工作是收集分布在不同機器的日志。收集器通常是按照應(yīng)用來分配收集任務(wù)單元，因此需要在ZK上創(chuàng)建一個以應(yīng)用名作為path的節(jié)點P，并將這個應(yīng)用的所有機器ip，以子節(jié)點的形式注冊到節(jié)點P上，這樣一來就能夠?qū)崿F(xiàn)機器變動的時候，能夠?qū)崟r通知到收集器調(diào)整任務(wù)分配。 系統(tǒng)中有些信息需要動態(tài)獲取，并且還會存在人工手動去修改這個信息的發(fā)問。通常是暴露出接口，例如JMX接口，來獲取一些運行時的信息。引入ZK之后，就不用自己實現(xiàn)一套方案了，只要將這些信息存放到指定的ZK節(jié)點上即可。 注意：在上面提到的應(yīng)用場景中，有個默認(rèn)前提是：數(shù)據(jù)量很小，但是數(shù)據(jù)更新可能會比較快的場景。

負載均衡

這里說的負載均衡是指軟負載均衡。在分布式環(huán)境中，為了保證高可用性，通常同一個應(yīng)用或同一個服務(wù)的提供方都會部署多份，達到對等服務(wù)。而消費者就須要在這些對等的服務(wù)器中選擇一個來執(zhí)行相關(guān)的業(yè)務(wù)邏輯，其中比較典型的是消息中間件中的生產(chǎn)者，消費者負載均衡。

命名服務(wù)(Naming Service)

命名服務(wù)也是分布式系統(tǒng)中比較常見的一類場景。在分布式系統(tǒng)中，通過使用命名服務(wù)，客戶端應(yīng)用能夠根據(jù)指定名字來獲取資源或服務(wù)的地址，提供者等信息。被命名的實體通?？梢允羌褐械臋C器，提供的服務(wù)地址，遠程對象等等——這些我們都可以統(tǒng)稱他們?yōu)槊郑∟ame）。其中較為常見的就是一些分布式服務(wù)框架中的服務(wù)地址列表。通過調(diào)用ZK提供的創(chuàng)建節(jié)點的API，能夠很容易創(chuàng)建一個全局唯一的path，這個path就可以作為一個名稱。

阿里巴巴集團開源的分布式服務(wù)框架Dubbo中使用ZooKeeper來作為其命名服務(wù)，維護全局的服務(wù)地址列表。在Dubbo實現(xiàn)中： 服務(wù)提供者在啟動的時候，向ZK上的指定節(jié)點/dubbo/${serviceName}/providers目錄下寫入自己的URL地址，這個操作就完成了服務(wù)的發(fā)布。 服務(wù)消費者啟動的時候，訂閱/dubbo/${serviceName}/providers目錄下的提供者URL地址， 并向/dubbo/${serviceName} /consumers目錄下寫入自己的URL地址。 注意，所有向ZK上注冊的地址都是臨時節(jié)點，這樣就能夠保證服務(wù)提供者和消費者能夠自動感應(yīng)資源的變化。

另外，Dubbo還有針對服務(wù)粒度的監(jiān)控，方法是訂閱/dubbo/${serviceName}目錄下所有提供者和消費者的信息。

分布式通知/協(xié)調(diào)

ZooKeeper中特有watcher注冊與異步通知機制，能夠很好的實現(xiàn)分布式環(huán)境下不同系統(tǒng)之間的通知與協(xié)調(diào)，實現(xiàn)對數(shù)據(jù)變更的實時處理。使用方法通常是不同系統(tǒng)都對ZK上同一個znode進行注冊，監(jiān)聽znode的變化（包括znode本身內(nèi)容及子節(jié)點的），其中一個系統(tǒng)update了znode，那么另一個系統(tǒng)能夠收到通知，并作出相應(yīng)處理。

另一種心跳檢測機制：檢測系統(tǒng)和被檢測系統(tǒng)之間并不直接關(guān)聯(lián)起來，而是通過zk上某個節(jié)點關(guān)聯(lián)，大大減少系統(tǒng)耦合。 另一種系統(tǒng)調(diào)度模式：某系統(tǒng)有控制臺和推送系統(tǒng)兩部分組成，控制臺的職責(zé)是控制推送系統(tǒng)進行相應(yīng)的推送工作。管理人員在控制臺作的一些操作，實際上是修改了ZK上某些節(jié)點的狀態(tài)，而ZK就把這些變化通知給他們注冊Watcher的客戶端，即推送系統(tǒng)，于是，作出相應(yīng)的推送任務(wù)。

另一種工作匯報模式：一些類似于任務(wù)分發(fā)系統(tǒng)，子任務(wù)啟動后，到zk來注冊一個臨時節(jié)點，并且定時將自己的進度進行匯報（將進度寫回這個臨時節(jié)點），這樣任務(wù)管理者就能夠?qū)崟r知道任務(wù)進度。

分布式鎖

分布式鎖，這個主要得益于ZooKeeper為我們保證了數(shù)據(jù)的強一致性。鎖服務(wù)可以分為兩類，一個是保持獨占，另一個是控制時序。

所謂保持獨占，就是所有試圖來獲取這個鎖的客戶端，最終只有一個可以成功獲得這把鎖。通常的做法是把zk上的一個znode看作是一把鎖，通過create znode的方式來實現(xiàn)。所有客戶端都去創(chuàng)建/distribute_lock節(jié)點，最終成功創(chuàng)建的那個客戶端也即擁有了這把鎖。 控制時序，就是所有視圖來獲取這個鎖的客戶端，最終都是會被安排執(zhí)行，只是有個全局時序了。做法和上面基本類似，只是這里/distribute_lock已經(jīng)預(yù)先存在，客戶端在它下面創(chuàng)建臨時有序節(jié)點（這個可以通過節(jié)點的屬性控制：CreateMode.EPHEMERAL_SEQUENTIAL來指定）。Zk的父節(jié)點（/distribute_lock）維持一份sequence,保證子節(jié)點創(chuàng)建的時序性，從而也形成了每個客戶端的全局時序。

由于同一節(jié)點下子節(jié)點名稱不能相同，所以只要在某個節(jié)點下創(chuàng)建znode，創(chuàng)建成功即表明加鎖成功。注冊監(jiān)聽器監(jiān)聽此znode，只要刪除此znode就通知其他客戶端來加鎖。創(chuàng)建臨時順序節(jié)點：在某個節(jié)點下創(chuàng)建節(jié)點，來一個請求則創(chuàng)建一個節(jié)點，由于是順序的，所以序號最小的獲得鎖，當(dāng)釋放鎖時，通知下一序號獲得鎖。

分布式隊列

隊列方面，簡單來說有兩種，一種是常規(guī)的先進先出隊列，另一種是等隊列的隊員聚齊以后才按照順序執(zhí)行。對于第一種的隊列和上面講的分布式鎖服務(wù)中控制時序的場景基本原理一致，這里就不贅述了。

第二種隊列其實是在FIFO隊列的基礎(chǔ)上作了一個增強。通常可以在/queue這個znode下預(yù)先建立一個/queue/num節(jié)點，并且賦值為n（或者直接給/queue賦值n），表示隊列大小，之后每次有隊列成員加入后，就判斷下是否已經(jīng)到達隊列大小，決定是否可以開始執(zhí)行了。這種用法的典型場景是，分布式環(huán)境中，一個大任務(wù)Task A，需要在很多子任務(wù)完成（或條件就緒）情況下才能進行。這個時候，凡是其中一個子任務(wù)完成（就緒），那么就去/taskList下建立自己的臨時時序節(jié)點（CreateMode.EPHEMERAL_SEQUENTIAL），當(dāng)/taskList發(fā)現(xiàn)自己下面的子節(jié)點滿足指定個數(shù)，就可以進行下一步按序進行處理了。

使用 dokcer-compose 搭建集群

上面我們介紹了關(guān)于 ZooKeeper 有這么多的應(yīng)用場景，那么接下來我們就先學(xué)習(xí)如何搭建 ZooKeeper 集群然后再進行實戰(zhàn)上面的應(yīng)用場景。

文件的目錄結(jié)構(gòu)如下：

├── docker-compose.yml

編寫 docker-compose.yml 文件

docker-compose.yml文件內(nèi)容如下：

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 端口綁定到對應(yīng)容器的 2181 端口上。

ZOO_MY_ID和ZOO_SERVERS是搭建 Zookeeper 集群需要的兩個環(huán)境變量。ZOO_MY_ID標(biāo)識服務(wù)的 id，為 1-255 之間的整數(shù)，必須在集群中唯一。ZOO_SERVERS是集群中的主機列表。

在docker-compose.yml所在目錄下執(zhí)行docker-compose up，可以看到啟動的日志。

連接 ZooKeeper

將集群啟動起來以后我們可以連接 ZooKeeper 對其進行節(jié)點的相關(guān)操作。

首先我們需要將 ZooKeeper 下載下來。ZooKeeper 下載地址。將其解壓進入其conf目錄中，將zoo_sample .cfg改成zoo.cfg

配置文件說明

# The number of milliseconds of each tick# tickTime：CS通信心跳數(shù)# Zookeeper 服務(wù)器之間或客戶端與服務(wù)器之間維持心跳的時間間隔，也就是每個 tickTime 時間就會發(fā)送一個心跳。tickTime以毫秒為單位。tickTime=2000# The number of ticks that the initial# synchronization phase can take# initLimit：LF初始通信時限# 集群中的follower服務(wù)器(F)與leader服務(wù)器(L)之間初始連接時能容忍的最多心跳數(shù)（tickTime的數(shù)量）。initLimit=5# The number of ticks that can pass between# sending a request and getting an acknowledgement# syncLimit：LF同步通信時限# 集群中的follower服務(wù)器與leader服務(wù)器之間請求和應(yīng)答之間能容忍的最多心跳數(shù)（tickTime的數(shù)量）。syncLimit=2# the directory where the snapshot is stored.# do not use /tmp for storage, /tmp here is just# example sakes.# dataDir：數(shù)據(jù)文件目錄# Zookeeper保存數(shù)據(jù)的目錄，默認(rèn)情況下，Zookeeper將寫數(shù)據(jù)的日志文件也保存在這個目錄里。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 服務(wù)器的端口，Zookeeper 會監(jiān)聽這個端口，接受客戶端的訪問請求。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# 服務(wù)器名稱與地址：集群信息（服務(wù)器編號，服務(wù)器地址，LF通信端口，選舉端口）# 這個配置項的書寫格式比較特殊，規(guī)則如下：# server.N=YYY:A:B# 其中N表示服務(wù)器編號，YYY表示服務(wù)器的IP地址，A為LF通信端口，表示該服務(wù)器與集群中的leader交換的信息的端口。B為選舉端口，表示選舉新leader時服務(wù)器間相互通信的端口（當(dāng)leader掛掉時，其余服務(wù)器會相互通信，選擇出新的leader）。一般來說，集群中每個服務(wù)器的A端口都是一樣，每個服務(wù)器的B端口也是一樣。但是當(dāng)所采用的為偽集群時，IP地址都一樣，只能時A端口和B端口不一樣。

可以不修改zoo.cfg，默認(rèn)配置就行，接下來在解壓后的 bin 目錄中執(zhí)行命令./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]

接下來我們可以使用命令查看節(jié)點了

使用 ls 命令查看當(dāng)前 ZooKeeper 中所包含的內(nèi)容

命令：ls /

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

[zookeeper] ```

創(chuàng)建了一個新的 znode 節(jié)點“ zk ”以及與它關(guān)聯(lián)的字符串

命令：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節(jié)點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節(jié)點zk

命令：delete /zk

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

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

由于篇幅有限，下篇文章會根據(jù)上面提到的 ZooKeeper 應(yīng)用場景逐一進行用代碼進行實現(xiàn)。

ZooKeeper 的Docker配置文件存放處

ZooKeeper 的Docker配置文件存放處

ZooKeeper 的Docker配置文件存放處

大家可以直接從上面拉取項目，啟動RocketMQ只需要兩步

從GitHub 上面拉取項目在 ZooKeeper 文件夾中執(zhí)行docker-compose up命令

參考文章

http://www.jucaiylzc.cn /2011/10/08/1232/
http://www.dongdongrji.cn /2019/04/25/1_Zookeeper%E8%AF%A6%E8%A7%A3/
https://www.jintianxuesha.com /cyfonly/p/5626532.html
http://www.hengxuangyul.com .com/docker-zookeeper-cluster/
https://www.qiaoheibpt.com maizitoday.github.io/post/zookeeper%E5%85%A5%E9%97%A8/

總結(jié)

到此這篇關(guān)于史上最便捷搭建Zookeeper服務(wù)器的方法的文章就介紹到這了,更多相關(guān)Zookeeper服務(wù)器搭建內(nèi)容請搜索以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持！