ZooKeeper 入門介紹

1. ZooKeeper 入門

1.1 是什么

ZooKeeper 是一個開源的分布式的,為分布式應(yīng)用提供協(xié)調(diào)服務(wù)的應(yīng)用。

工作機制:

ZooKeeper 從設(shè)計模式角度來理解:是一個基于觀察者模式的分布式服務(wù)管理框架,它負責存儲和管理大家都關(guān)心的數(shù)據(jù),然后接受觀察者的注冊,一旦這些數(shù)據(jù)的狀態(tài)發(fā)生變化,ZooKeeper 就將負責通知已經(jīng)在 ZooKeeper 上注冊的那些觀察者做出相應(yīng)的反應(yīng)。

ZooKeeper = 文件系統(tǒng)+通知機制

1.2 特點:

ZooKeeper特點.png

1)ZooKeeper:一個領(lǐng)導(dǎo)者(Leader),多個跟隨者(Follower)組成的集群;

2)集群只要有半數(shù)以上的節(jié)點存活,ZooKeeper 集群就能正常服務(wù)。

3)全局數(shù)據(jù)一致:每個 Server 保存一份相同的數(shù)據(jù)副本,Client 無論連接到哪個 Server,數(shù)據(jù)都是一致的。

4)更新請求順序進行,一次數(shù)據(jù)更新要么成功,要么失敗。

5)數(shù)據(jù)更新原子性,一次數(shù)據(jù)更新要么成功,要么失敗。

6)實時性,在一定時間范圍內(nèi),Client 能讀到最新數(shù)據(jù)。

1.3 ZooKeeper 數(shù)據(jù)結(jié)構(gòu)

ZK數(shù)據(jù)結(jié)構(gòu).png

ZooKeeper 數(shù)據(jù)模型的結(jié)構(gòu)與 Unix 文件系統(tǒng)很類似,整體上可以看做是一棵樹,每個節(jié)點稱作一個 ZNode。每一個 ZNode 默認能夠存儲 1MB 的數(shù)據(jù),每個 ZNode 都可以通過其路徑唯一標識。

1.4 應(yīng)用場景

提供的服務(wù)包括:統(tǒng)一命名服務(wù)、統(tǒng)一配置管理、統(tǒng)一集群管理、服務(wù)器節(jié)點動態(tài)上下線、軟負載均衡等。

  • 統(tǒng)一命名服務(wù)
應(yīng)用場景-統(tǒng)一命名服務(wù).png

在分布式環(huán)境下,經(jīng)常需要對應(yīng)用/服務(wù)進行統(tǒng)一命名,便于識別。
例如:IP 不容易記住,而域名容易記住。

  • 統(tǒng)一配置管理


    應(yīng)用場景-統(tǒng)一配置管理.png
  1. 分布式環(huán)境下,配置文件同步非常常見。

(1)一般要求一個集群中,所有節(jié)點的配置信息是一致的,比如 Kafka 集群。

(2)對配置文件修改后,希望能夠快速同步到各個節(jié)點上。

2)配置管理可交由 ZooKeeper 實現(xiàn)。

(1)可將配置信息寫入 ZooKeeper 上的一個 Znode。

(2)各個客戶端服務(wù)監(jiān)聽這個 Znode。

(3)一旦 Znode 中的數(shù)據(jù)被修改,ZooKeeper 將通知各個客戶端服務(wù)器。

  • 統(tǒng)一集群管理
應(yīng)用場景-統(tǒng)一集群管理.png

1)分布式環(huán)境中,實時掌握每個節(jié)點的狀態(tài)是必要的。

(1)可根據(jù)節(jié)點實時狀態(tài)做出一些調(diào)整。

2)ZooKeeper 可以實現(xiàn)實時監(jiān)控節(jié)點狀態(tài)變化

(1)可將節(jié)點信息寫入 ZooKeeper 上的一個 ZNode。

(2)監(jiān)聽這個 ZNode 可獲取它的實時狀態(tài)變化。

  • 服務(wù)器動態(tài)上下線
應(yīng)用場景-服務(wù)器動態(tài)上下線.png

客戶端能實時洞察到服務(wù)器上下線的變化。

  • 軟負載均衡
應(yīng)用場景-軟負載均衡.png
在 ZooKeeper 中記錄沒太服務(wù)器的訪問數(shù),讓訪問數(shù)最少的服務(wù)器去處理最新的客戶端請求。

2. ZooKeeper 安裝配置

2.1 安裝 部署

1)安裝

學(xué)習環(huán)境Mac通過 brew 安裝,過程略....
TODO:Linux 集群安裝待補充......

  1. 配置修改

brew 安裝 ZooKeeper 安裝配置文件位于/usr/local/etc/zookeeper下;

實際生產(chǎn)中 Linux 位于 ZooKeeper 安裝目錄 conf 下。

修改如下內(nèi)容:dataDir=/opt/module/zookeeper-3.4.10/zkData

(3)在/opt/module/zookeeper-3.4.10/這個目錄上創(chuàng)建zkData文件夾

3)操作 ZooKeeper

以下操作場景為mac 環(huán)境下 brew 本地安裝ZooKeeper演示環(huán)境,Linux 環(huán)境略有不同。

? (3)啟動客戶端

?  ~ zkCli
Connecting to localhost:2181
Welcome to ZooKeeper!
JLine support is enabled
WATCHER::
WatchedEvent state:SyncConnected type:None path:null
[zk: localhost:2181(CONNECTED) 0]

? (4)退出客戶端

[zk: localhost:2181(CONNECTED) 0] quit
Quitting...

? (5)停止 ZooKeeper

?  ~ zkserver stop
ZooKeeper JMX enabled by default
Using config: /usr/local/etc/zookeeper/zoo.cfg
Stopping zookeeper ... STOPPED

2.2 配置參數(shù)解讀

Zookeeper中的配置文件zoo.cfg中參數(shù)含義解讀如下:

1.tickTime =2000:通信心跳數(shù),Zookeeper服務(wù)器與客戶端心跳時間,單位毫秒

Zookeeper使用的基本時間,服務(wù)器之間或客戶端與服務(wù)器之間維持心跳的時間間隔,也就是每個tickTime時間就會發(fā)送一個心跳,時間單位為毫秒。

它用于心跳機制,并且設(shè)置最小的session超時時間為兩倍心跳時間。(session的最小超時時間是2*tickTime)

2.initLimit =10:LF初始通信時限

集群中的Follower跟隨者服務(wù)器與Leader領(lǐng)導(dǎo)者服務(wù)器之間初始連接時能容忍的最多心跳數(shù)(tickTime的數(shù)量),用它來限定集群中的Zookeeper服務(wù)器連接到Leader的時限。

3.syncLimit =5:LF同步通信時限

集群中Leader與Follower之間的最大響應(yīng)時間單位,假如響應(yīng)超過syncLimit * tickTime,Leader認為Follwer死掉,從服務(wù)器列表中刪除Follwer。

4.dataDir:數(shù)據(jù)文件目錄+數(shù)據(jù)持久化路徑

主要用于保存Zookeeper中的數(shù)據(jù)。

5.clientPort =2181:客戶端連接端口

監(jiān)聽客戶端連接的端口。

3. ZooKeeper 內(nèi)部原理

3.1 選舉機制

1)半數(shù)機制:集群中半數(shù)以上機器存活,集群可用。所以Zookeeper適合安裝奇數(shù)臺服務(wù)器。

2)Zookeeper雖然在配置文件中并沒有指定Master和Slave。但是,Zookeeper工作時,是有一個節(jié)點為Leader,其他則為Follower,Leader是通過內(nèi)部的選舉機制臨時產(chǎn)生的。

3)以一個簡單的例子來說明整個選舉的過程。

假設(shè)有五臺服務(wù)器組成的Zookeeper集群,它們的id從1-5,同時它們都是最新啟動的,也就是沒有歷史數(shù)據(jù),在存放數(shù)據(jù)量這一點上,都是一樣的。假設(shè)這些服務(wù)器依序啟動,來看看會發(fā)生什么,如圖所示。

選舉機制.png

(1)服務(wù)器1啟動,此時只有它一臺服務(wù)器啟動了,它發(fā)出去的報文沒有任何響應(yīng),所以它的選舉狀態(tài)一直是LOOKING狀態(tài)。

(2)服務(wù)器2啟動,它與最開始啟動的服務(wù)器1進行通信,互相交換自己的選舉結(jié)果,由于兩者都沒有歷史數(shù)據(jù),所以id值較大的服務(wù)器2勝出,但是由于沒有達到超過半數(shù)以上的服務(wù)器都同意選舉它(這個例子中的半數(shù)以上是3),所以服務(wù)器1、2還是繼續(xù)保持LOOKING狀態(tài)。

(3)服務(wù)器3啟動,根據(jù)前面的理論分析,服務(wù)器3成為服務(wù)器1、2、3中的老大,而與上面不同的是,此時有三臺服務(wù)器選舉了它,所以它成為了這次選舉的Leader。

(4)服務(wù)器4啟動,根據(jù)前面的分析,理論上服務(wù)器4應(yīng)該是服務(wù)器1、2、3、4中最大的,但是由于前面已經(jīng)有半數(shù)以上的服務(wù)器選舉了服務(wù)器3,所以它只能接收當小弟的命了。

(5)服務(wù)器5啟動,同4一樣當小弟。

關(guān)于ZooKeeper選舉機制的更多介紹,請參考:http://m.itdecent.cn/p/3476587a6fa1

3.2 節(jié)點類型

節(jié)點類型.png
?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請聯(lián)系作者
【社區(qū)內(nèi)容提示】社區(qū)部分內(nèi)容疑似由AI輔助生成,瀏覽時請結(jié)合常識與多方信息審慎甄別。
平臺聲明:文章內(nèi)容(如有圖片或視頻亦包括在內(nèi))由作者上傳并發(fā)布,文章內(nèi)容僅代表作者本人觀點,簡書系信息發(fā)布平臺,僅提供信息存儲服務(wù)。

相關(guān)閱讀更多精彩內(nèi)容

友情鏈接更多精彩內(nèi)容