史上最便捷搭建 Zookeeper 的方法!

點擊關注公衆號,Java乾貨及時送達

作者:不學無數的程序員
鏈接:www.jianshu.com/p/6d349acf48aa

什麼是 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 節點上,供訂閱者動態獲取數據,實現配置信息的集中式管理和動態更新。例如全局的配置信息,服務式服務框架的服務地址列表等就非常適合使用。

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

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

分佈式日誌收集系統

這個系統的核心工作是收集分佈在不同機器的日誌。收集器通常是按照應用來分配收集任務單元,因此需要在 ZooKeeper 上創建一個以應用名作爲 path 的節點 P,並將這個應用的所有機器 IP,以子節點的形式註冊到節點 P 上。這樣一來就能夠實現機器變動的時候,能夠實時通知到收集器調整任務分配。

系統中有些信息需要動態獲取,並且還會存在人工手動去修改這個信息的發問。通常是暴露出接口,例如 JMX 接口,來獲取一些運行時的信息。引入 ZooKeeper 之後,就不用自己實現一套方案了,只要將這些信息存放到指定的 ZooKeeper 節點上即可。

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

負載均衡

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

命名服務(Naming Service)

命名服務也是分佈式系統中比較常見的一類場景。在分佈式系統中,通過使用命名服務,客戶端應用能夠根據指定名字來獲取資源或服務的地址,提供者等信息。被命名的實體通常可以是集羣中的機器,提供的服務地址,遠程對象等等——這些我們都可以統稱它們爲名字(Name)。

其中較爲常見的就是一些分佈式服務框架中的服務地址列表。通過調用 ZooKeeper 提供的創建節點的 API,能夠很容易創建一個全局唯一的path,這個 path 就可以作爲一個名字。

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

  • 服務提供者在啓動的時候,向 ZooKeeper 上的指定節點 /dubbo/${serviceName}/providers 目錄下寫入自己的 URL 地址,這個操作就完成了服務的發佈。
  • 服務消費者啓動的時候,訂閱 /dubbo/ {serviceName} /consumers 目錄下寫入自己的 URL 地址。

注意:所有向 ZooKeeper 上註冊的地址都是臨時節點,這樣就能夠保證服務提供者和消費者能夠自動感應資源的變化。

另外,Dubbo 還有針對服務粒度的監控。方法是訂閱 /dubbo/${serviceName} 目錄下所有提供者和消費者的信息。另外,關注公衆號Java技術棧,在後臺回覆:面試,可以獲取我整理的 Dubbo 系列面試題和答案,非常齊全。

分佈式通知/協調

ZooKeeper 中特有 Watcher 註冊與異步通知機制,能夠很好的實現分佈式環境下不同系統之間的通知與協調,實現對數據變更的實時處理。使用方法通常是不同系統都對 ZooKeeper 上同一個 Znode 進行註冊,監聽 Znode 的變化(包括 Znode 本身內容及子節點的),其中一個系統 Update 了 Znode,那麼另一個系統能夠收到通知,並作出相應處理。

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

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

另一種工作彙報模式:一些類似於任務分發系統。子任務啓動後,到 ZooKeeper 來註冊一個臨時節點,並且定時將自己的進度進行彙報(將進度寫回這個臨時節點)。這樣任務管理者就能夠實時知道任務進度。

分佈式鎖

分佈式鎖主要得益於 ZooKeeper 爲我們保證了數據的強一致性。鎖服務可以分爲兩類:一類是保持獨佔,另一類是控制時序。Spring Boot Redis 實現分佈式鎖,推薦看下。

所謂保持獨佔,就是所有試圖來獲取這個鎖的客戶端,最終只有一個可以成功獲得這把鎖。通常的做法是把 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,可以看到啓動的日誌。使用 Docker 部署 Spring Boot 項目,推薦看下。

連接 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 myDataCreated /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 /zkmyDatacZxid = 0x400000008ctime = Mon Jun 01 15:07:50 CST 2020mZxid = 0x400000008mtime = Mon Jun 01 15:07:50 CST 2020pZxid = 0x400000008cversion = 0dataVersion = 0aclVersion = 0ephemeralOwner = 0x0dataLength = 6numChildren = 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 應用場景逐一進行用代碼進行實現。最後,關注公衆號Java技術棧,在後臺回覆:面試,可以獲取我整理的 Java、ZK 系列面試題和答案,非常齊全。






關注Java技術棧看更多幹貨



獲取 Spring Boot 實戰筆記!

本文分享自微信公衆號 - Java技術棧(javastack)。
如有侵權,請聯繫 [email protected] 刪除。
本文參與“OSC源創計劃”,歡迎正在閱讀的你也加入,一起分享。

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章