2021-02-14 分類: 網(wǎng)站建設(shè)
Zookeeper是分布式一致性問題的工業(yè)解決方案,是Apache Hadoop下解決分布式一致性的一個組件,后被分離出來成為Apache的頂級項目。
工程來源:是雅虎公司內(nèi)部項目,據(jù)說雅虎內(nèi)部很多項目都是以動物命名,這個動物管理員的名字起的很是形象。
被開源出來后得到開源社區(qū)的快速推進(jìn),服務(wù)端Java語言實現(xiàn),棒,git有3000+的star:
https://github.com/apache/zookeeper
zookeeper集群結(jié)構(gòu)
集群的角色,比較典型的是Master/Slave(主備模式),zk中的概念跟這個不一樣,包含Leader、Follower、Observer三個角色,leader提供讀和寫的能力,follower只對外提供讀的能力。
會話(session)
客戶端跟服務(wù)端交互,是先與服務(wù)端建立一個TCP長連接,會話開始,通過心跳檢測與服務(wù)端保持會話有效,向服務(wù)端發(fā)送請求和接收響應(yīng)。
zk將所有的數(shù)據(jù)都加載在內(nèi)存一份,同時有事務(wù)日志文件(持久化文件),服務(wù)端會定時dump快照數(shù)據(jù),重啟機器的時候會根據(jù)快照和事務(wù)日志恢復(fù)內(nèi)存數(shù)據(jù)庫的數(shù)據(jù),這跟redis的AOF和RDB概念類似。
zookeeper上的數(shù)據(jù)結(jié)構(gòu)
zk上的數(shù)據(jù)的結(jié)構(gòu)跟linux文件系統(tǒng)很像,是個樹狀結(jié)構(gòu)
節(jié)點(node)上的信息字段
節(jié)點類型包括:
其中臨時節(jié)點特性就是創(chuàng)建它的主體消失后,它就跟著消失了。后續(xù)的應(yīng)用就是利用的節(jié)點的特性實現(xiàn)的。
事件監(jiān)聽器(watcher)
這個應(yīng)該是zookeeper最重要的概念之一了,zk允許用戶在特定的節(jié)點(znode)上注冊watcher,并且在特定事件觸發(fā)的時候,zk服務(wù)端會將事件通知到感興趣的客戶端上。
偽集群的搭建:
zoo.cfg 配置文件
啟動成功后,命令行連接zk,可以用指令做些增刪改查的操作
telnet 127.0.0.1 2181
stat:可以看集群的狀態(tài)信息
stat信息
每次事務(wù)操作,會在dataDir的目錄下的事務(wù)日志,是序列化的二進(jìn)制文件,zookeeper提供了查看事務(wù)日志的工具類LogFormatter
LogFormatter轉(zhuǎn)換后的事務(wù)日志文件
Java客戶端使用
cruator客戶端例子
zookeeper應(yīng)用場景
利用zookeeper的特性,可以比較方便的構(gòu)建分布式應(yīng)用會涉及的核心功能,比如:配置中心、命名服務(wù)、分布式協(xié)調(diào)/通知、集群的管理、master選舉、分布式鎖等
以下應(yīng)用基本基于zookeeper的兩大特性實現(xiàn)
--配置中心:
配置中心
zookeeper利用推拉結(jié)合的方式,客戶端向服務(wù)端注冊自己需要關(guān)注的節(jié)點,一旦該數(shù)據(jù)發(fā)生變更,那么服務(wù)器就會向相應(yīng)的客戶端發(fā)送watcher時間通知。
客戶收到這個消息通知之后,再主動到服務(wù)端獲取最新的數(shù)據(jù)。即回調(diào)的event中包含具體的數(shù)據(jù)。
這個應(yīng)用的的業(yè)務(wù)員特點:
--命名服務(wù)
利用zookeeper的順序節(jié)點,樹形結(jié)構(gòu)的數(shù)據(jù)特點,實現(xiàn)命名服務(wù):
這樣RPC的客戶端只需要傳對應(yīng)的服務(wù)名字,和接口,就能找到對應(yīng)的服務(wù)。
使用zookeeper實現(xiàn):不同的業(yè)務(wù)下創(chuàng)建一個節(jié)點,具體的節(jié)點下用zk的順序節(jié)點(sequent)生成id當(dāng)做這個業(yè)務(wù)的全局唯一id使用
--分布式通知/協(xié)調(diào)
ZooKeeper中特有watcher注冊與異步通知機制,能夠很好的實現(xiàn)分布式環(huán)境下不同系統(tǒng)之間的通知與協(xié)調(diào),實現(xiàn)對數(shù)據(jù)變更的實時處理。
使用方法通常是不同系統(tǒng)都對ZK上同一個znode進(jìn)行注冊,監(jiān)聽znode的變化(包括znode本身內(nèi)容及子節(jié)點的),其中一個系統(tǒng)update了znode,那么另一個系統(tǒng)能夠收到通知,并作出相應(yīng)處理。
應(yīng)用:
心跳檢測機制:傳統(tǒng)的方式是ping,復(fù)雜的話是建立長連接檢測系統(tǒng)和被檢測系統(tǒng)之間并不直接關(guān)聯(lián)起來,而是通過zookeeper上某個節(jié)點關(guān)聯(lián),大大減少系統(tǒng)耦合
系統(tǒng)調(diào)度模式:某系統(tǒng)由控制臺和推送系統(tǒng)兩部分組成,控制臺的職責(zé)是控制推送系統(tǒng)進(jìn)行相應(yīng)的推送工作。
管理人員在控制臺作的一些操作,實際上是修改了ZK上某些節(jié)點的狀態(tài),而ZK就把這些變化通知給他們注冊Watcher的客戶端,即推送系統(tǒng)。于是,作出相應(yīng)的推送任務(wù)
作匯報模式:一些類似于任務(wù)分發(fā)系統(tǒng),子任務(wù)啟動后,到ZK來注冊一個臨時節(jié)點,并且定時將自己的進(jìn)度進(jìn)行匯報(將進(jìn)度寫回這個臨時節(jié)點)
總之,使用zookeeper來進(jìn)行分布式通知和協(xié)調(diào)能夠大大降低系統(tǒng)之間的耦合。
--分布式鎖
這個應(yīng)用主要得益于ZooKeeper為我們保證了數(shù)據(jù)的強一致性
即用戶只要完全相信每時每刻,zk集群中任意節(jié)點(一個zk server)上的相同znode的數(shù)據(jù)是一定是相同的。
一個節(jié)點要么創(chuàng)建成功,要么失敗,并且只由一個客戶端創(chuàng)建。
獨占鎖:
保持獨占,就是所有試圖來獲取這個鎖的客戶端,最終只有一個可以成功獲得這把鎖。
通常的做法是把ZK上的一個znode看作是一把鎖,通過create znode的方式來實現(xiàn)。所有客戶端都去創(chuàng)建/distribute_lock節(jié)點,最終成功創(chuàng)建的那個客戶端也即擁有了這把鎖。
共享時序控制鎖:
Zookeeper很容易實現(xiàn)這個功能,實現(xiàn)方式是需要獲得鎖的Server,創(chuàng)建一個EPHEMERAL_SEQUENTIAL目錄節(jié)點。
然后調(diào)用getChildren方法獲取當(dāng)前的目錄節(jié)點列表中最小的目錄節(jié)點是不是就是自己創(chuàng)建的目錄節(jié)點。
如果正是自己創(chuàng)建的,那么它就獲得了這個鎖,如果不是,那么它就調(diào)用exists(String path, boolean watch)方法,并監(jiān)控Zookeeper上目錄節(jié)點列表的變化,一直到自己創(chuàng)建的節(jié)點是列表中最小編號的目錄節(jié)點,從而獲得鎖。
釋放鎖很簡單,只要刪除前面它自己所創(chuàng)建的目錄節(jié)點就行了。
--master選舉
master選舉應(yīng)用圖
有個容易理解的方案,依靠關(guān)系型數(shù)據(jù)庫主鍵的特性,集群的機器同時往一張表里插入數(shù)據(jù),數(shù)據(jù)庫會自動進(jìn)行主鍵沖突檢查,可以選擇插入成功的客戶端作為master
這種方式存在一個問題就是,master機器掛了,沒有人通知
zk實現(xiàn)可以方便做到這一點:zk的創(chuàng)建節(jié)點api接口,具有強一致性,能夠保證客戶端并發(fā)創(chuàng)建的時候,最終一定只有一個客戶端創(chuàng)建成功。
--集群管理
應(yīng)用舉例:集群機器存活性監(jiān)控系統(tǒng),例如:
監(jiān)控系統(tǒng)在/clusterServers節(jié)點注冊一個watcher監(jiān)聽,那么但凡進(jìn)行動態(tài)添加機器的操作,就在/clusterServers下創(chuàng)建一個臨時節(jié)點, /clusterServers/ip。
這樣監(jiān)控系統(tǒng)就能夠?qū)崟r的檢測到機器的變動,通過getChild方法獲取所有的臨時節(jié)點,來判斷增加的機器。
當(dāng)有機器down調(diào)或者手動下線,相應(yīng)臨時節(jié)點會消失,監(jiān)控系統(tǒng)也會接收到,來處理監(jiān)控服務(wù)的具體業(yè)務(wù)
具體服務(wù)器部署agent實現(xiàn)
zookeeper的HA設(shè)計實現(xiàn)
以上說了那么多犀利實用的應(yīng)用場景,它們依賴zookeeper,說明這些應(yīng)用服務(wù)的高可用性依賴的zookeeper本身的HA。
zk的選舉算法
算法協(xié)議zab協(xié)議,“少數(shù)服從多數(shù)”協(xié)議一種
3.4.0版本之后Zookeeper只保留了TCP版本的FastLeaderElection選舉算法
分析選舉算法前,先熟悉了解下zk的一些術(shù)語定義解釋:
當(dāng)哪些情況發(fā)生時會出發(fā)leader重新選舉呢?
當(dāng)zk的一臺服務(wù)器出現(xiàn)以下兩種情況的時候,會進(jìn)入leader選舉流程
對于第一種情況,即已經(jīng)存在一臺leader服務(wù)器,當(dāng)改機器試圖去選舉leader的時候,會被告知當(dāng)前服務(wù)器的leader信息,對于該機器僅僅需要和leader建立連接,并進(jìn)行狀態(tài)同步即可
主要看下第二種情況:
有兩種情況導(dǎo)致集群不存在leader,一個是集群剛啟動初始化的時候,另一種情況是運行期間leader所在服務(wù)器掛了。
無論哪種情況集群所有集群都處在一個找leader的狀態(tài),稱作Looking狀態(tài),開始想其他機器發(fā)送消息投票
開始leader選舉投票的協(xié)議規(guī)則是怎樣呢?
5臺機器宕機兩臺后,leader選舉的過程圖示
因此,一個錯誤的認(rèn)識,為了使zookeeper集群能順利的選出leader,必須將zookeeper集群的服務(wù)器數(shù)部署為奇數(shù)。
從上邊例子能看出來部署任意臺機器都能夠正常選舉運行。部署奇數(shù)臺是官方給的建議,因為奇數(shù)和奇數(shù)+1的容災(zāi)能力是一樣的。比如:
5臺服務(wù)器,能夠?qū)?臺機器掛掉的情況進(jìn)程容災(zāi)
6臺服務(wù)器,能夠?qū)?臺機器掛掉的情況進(jìn)程容災(zāi),如果掛掉3臺,剩下的機器就無法實現(xiàn)過半了。
網(wǎng)站名稱:分布式高并發(fā),ZooKeeper架構(gòu)及原理
網(wǎng)站路徑:http://m.newbst.com/news12/100862.html
成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián),為您提供品牌網(wǎng)站建設(shè)、全網(wǎng)營銷推廣、網(wǎng)站建設(shè)、微信公眾號、App設(shè)計、定制網(wǎng)站
聲明:本網(wǎng)站發(fā)布的內(nèi)容(圖片、視頻和文字)以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主,如果涉及侵權(quán)請盡快告知,我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場,如需處理請聯(lián)系客服。電話:028-86922220;郵箱:631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載,或轉(zhuǎn)載時需注明來源: 創(chuàng)新互聯(lián)
猜你還喜歡下面的內(nèi)容