持续更新的Zookeeper知识总结
簡介
Zookeeper為分布式應(yīng)用 提供了高效且可靠的分布式協(xié)調(diào)服務(wù)，提供了諸如統(tǒng)一命名服務(wù)、發(fā)布訂閱、負載均衡、配置管理和分布式鎖等分布式的基礎(chǔ)服務(wù)。
設(shè)計目標(biāo)是將那些復(fù)雜且容易出錯的分布式一致性服務(wù)封裝起來，構(gòu)成一個高效可靠的原語集，并以一系列簡單易用的接口提供給用戶使用。
可以保證以下特性：
基本概念/原理
集群角色
通常在分布式系統(tǒng)中，構(gòu)成一個集群的每一臺機器都有自己的角色，最典型的集群模式就是Master/Slave模式。而在Zookeeper中，引入了Leader、Follower、Observer（可以沒有）三種角色。Zookeeper集群中的所有機器通過一個Leader選舉過程選定一臺被稱為“Leader”的機器，Leader服務(wù)器為客戶端提供讀和寫服務(wù)。Follower和Observer都能提供讀服務(wù)，唯一的區(qū)別是，Observer機器不參與Leader選舉過程，也不參與寫操作的“過半寫成功”策略，因此Observer可以在不影響寫性能的情況下提升集群的讀性能。
?
Leader是整個Zookeeper集群工作機制的核心，主要工作有以下兩個：
1）事務(wù)請求的唯一調(diào)度和處理者，保證集群事務(wù)處理的順序性
2）集群內(nèi)部各服務(wù)器的調(diào)度者
Follower是Zookeeper集群狀態(tài)的跟隨者，其主要工作有以下三個：
1）處理客戶端非事務(wù)請求，轉(zhuǎn)發(fā)事務(wù)請求給Leader
2）參與事務(wù)請求Proposal的投票
3）參與Leader選舉
?
Observer和Follower很像，唯一的區(qū)別是不參與任何形式的投票，只提供非事務(wù)服務(wù)通常用在不影響集群事務(wù)處理能力的前提下提升集群的非事務(wù)處理能力。
事務(wù)
在Zookeeper中，事務(wù)是指能夠改變Zookeeper服務(wù)器狀態(tài)的操作，我們稱之為事務(wù)操作。對于每一個事務(wù)請求，Zookeeper都會為其分配一個全局唯一的事務(wù)iD，用ZXID表示，通常是一個64位的數(shù)字。每一個ZXID對應(yīng)一次更新操作，從ZXID中可以識別出Zookeeper處理這些更新操作請求的全局順序。
會話
Session是指客戶端會話。一個客戶端連接是指客戶端和服務(wù)器之間的一個TCP長連接。從第一次連接建立開始，客戶端會話的生命周期也開始了，通過這個連接，客戶端能夠提供心跳檢測與服務(wù)器保持有效的會話，也能夠向Zookeeper服務(wù)器發(fā)送請求并接收響應(yīng)，同時還能通過該連接接收來自服務(wù)器的Watch事件通知。Session的sessionTimeout值用來設(shè)置一個客戶端會話的超時時間。當(dāng)由于服務(wù)器壓力太大、網(wǎng)絡(luò)故障或者客戶端主動斷開連接等各種原因?qū)е驴蛻舳诉B接斷開時，只要在sessionTimeout規(guī)定的時間內(nèi)能夠重新連接上集群中任意一臺機器，那么之前創(chuàng)建的會話仍然有效。
數(shù)據(jù)節(jié)點 ZNode
Zookeeper將所有數(shù)據(jù)存儲在內(nèi)存中，數(shù)據(jù)模型是一棵樹，由/進行分割的路徑，就是一個ZNode（比如/foo/path1）。每個ZNode都會保存自己的數(shù)據(jù)內(nèi)容，同時保存一系列屬性信息。
ZNode可以分為持久節(jié)點和臨時節(jié)點。持久節(jié)點是指一旦這個ZNode被創(chuàng)建了，除非主動進行ZNode的移除操作，否則這個ZNode將一直保存在Zookeeper上。而臨時節(jié)點的生命周期與客戶端會話綁定，一旦客戶端會話失效，那么這個客戶端創(chuàng)建的所有臨時節(jié)點都會被移除。另外，Zookeeper還允許用戶為每個節(jié)點添加一個SEQUENTIAL。一旦節(jié)點被標(biāo)記上這個屬性，那么在這個節(jié)點被創(chuàng)建的時候，Zookeeper會自動在其節(jié)點名后面追加上一個整型數(shù)字，這個整型數(shù)字是一個由父節(jié)點維護的自增數(shù)字。
數(shù)據(jù)節(jié)點分為持久節(jié)點、臨時節(jié)點和順序節(jié)點，可以生成四種組合：持久、持久順序、臨時、臨時順序。
?
版本
對應(yīng)每個ZNode，Zookeeper都會為其維護一個叫做Stat的數(shù)據(jù)結(jié)構(gòu)，Stat中記錄了這個ZNode 的三個數(shù)據(jù)版本，分別是version（當(dāng)前ZNode版本）、cversion（當(dāng)前ZNode子節(jié)點的版本）和aversion（當(dāng)前ZNode的ACL版本）。還有czxid（創(chuàng)建時的事務(wù)ID），mzxid（最后一個被更新時的事務(wù)ID）等。
version為0表示自創(chuàng)建該節(jié)點后，被更新過0次。注意即使變更并沒有使得數(shù)據(jù)內(nèi)容的值發(fā)生變化，version的值仍然會變更。
版本的作用可以用樂觀鎖原理來解釋，更新數(shù)據(jù)的時候ZK使用樂觀鎖來保證原子性。
Watcher
Zookeeper允許用戶在指定節(jié)點上注冊一些Watcher，并且在一些特定事件觸發(fā)的時候，Zookeeper服務(wù)器會將事件通知到感興趣的客戶端上去。
Watcher機制包括客戶端線程、客戶端WatchManager和ZK服務(wù)器三部分。客戶端在向ZK服務(wù)器注冊Watcher的同時，會將Watcher對象存儲在客戶端的WatchManager中。當(dāng)Zookeeper服務(wù)器觸發(fā)Watcher事件后，會向客戶端發(fā)送通知，客戶端線程從WatchManager中取出對應(yīng)的Watcher對象來執(zhí)行回調(diào)邏輯。
KeeperState和EventType兩個枚舉分別代表了通知狀態(tài)和事件類型。
?
注意，客戶端無法直接從該事件中獲取到對應(yīng)數(shù)據(jù)節(jié)點的原始數(shù)據(jù)內(nèi)容以及變更后的新數(shù)據(jù)內(nèi)容，而是需要客戶端再次主動去重新獲取數(shù)據(jù)。
?
Watcher特性：
1）一次性：無論是服務(wù)器還是客戶端，一旦一個Watcher被觸發(fā)，ZK都會將其從相應(yīng)的存儲中移除。因此開發(fā)人員必須要進行反復(fù)注冊，這樣的設(shè)計有效地減輕了服務(wù)器的壓力
2）客戶端串行執(zhí)行：Watcher的回調(diào)是一個串行同步的過程，這為我們保證了順序。
3）輕量：WatchedEvent是ZK整個Watcher通知機制的最小通知單元，只包含通知狀態(tài)、事件類型和節(jié)點路徑。
ACL
Zookeeper使用ACL（訪問控制列表）策略來進行權(quán)限控制，避免因誤操作而帶來的數(shù)據(jù)隨意變更導(dǎo)致的分布式系統(tǒng)異常。
Zookeeper定義了5種權(quán)限：
CREATE：創(chuàng)建節(jié)點
READ：讀取節(jié)點數(shù)據(jù)和子節(jié)點列表
WRITE：更新節(jié)點數(shù)據(jù)的權(quán)限
DELETE：刪除子節(jié)點
ADMIN：設(shè)置節(jié)點ACL
?
?
ZAB協(xié)議
ZAB：Zookeeper Atomic Broadcast 原子消息廣播協(xié)議
核心
1） Zookeeper使用一個單一的主進程來接收并處理客戶端的所有事務(wù)請求，并采用ZAB的原子廣播協(xié)議，將服務(wù)器數(shù)據(jù)的狀態(tài)變更以事務(wù)Proposal的形式廣播到所有的副本進程上去。ZAB協(xié)議的這個主備模型架構(gòu)保證了同一時刻集群中只能有一個主進程來廣播服務(wù)器的狀態(tài)變更，因此能夠很好地處理客戶端大量的并發(fā)請求。
2） 在分布式環(huán)境中，順序執(zhí)行的一些狀態(tài)變更其前后存在一定的依賴關(guān)系，有些狀態(tài)變更必須依賴于比它早生成的那些狀態(tài)變更。ZAB協(xié)議必須能夠保證一個全局的變更序列被順序地應(yīng)用。
3）所有事務(wù)請求必須由一個全局唯一的服務(wù)器來協(xié)調(diào)處理，這樣的服務(wù)器被稱為Leader服務(wù)器，而余下的服務(wù)器則稱為Follower。Leader負責(zé)將一個客戶端事務(wù)請求轉(zhuǎn)換成一個Proposal，并將該Proposal分發(fā)給集群中所有的Follower服務(wù)器。之后Leader需要等待所有Follower的反饋，一旦超過半數(shù)的Follower進行了正確的反饋后，那么Leader就會再次向所有的Follower分發(fā)Commit消息，要求其將前一個Proposal進行提交。
?
內(nèi)容介紹
ZAB協(xié)議包括兩種基本的模式，分別是崩潰恢復(fù)和消息廣播。當(dāng)整個服務(wù)框架在啟動過程中，或是當(dāng)Leader出現(xiàn)網(wǎng)絡(luò)中斷、崩潰退出等異常情況時，ZAB協(xié)議就會進入恢復(fù)模式，并選舉產(chǎn)生新的Leader。當(dāng)選舉產(chǎn)生了新的Leader服務(wù)器，同時集群中已經(jīng)有過半的機器與該Leader服務(wù)器完成了狀態(tài)同步（數(shù)據(jù)同步）之后，ZAB協(xié)議就會退出恢復(fù)模式。
?
當(dāng)集群中已經(jīng)有過半的Follower完成了與Leader的狀態(tài)同步，那么整個服務(wù)器框架就可以進入消息廣播模式。當(dāng)一臺同樣遵循ZAB協(xié)議的服務(wù)器啟動后加入到集群中時，如果此時集群中已經(jīng)存在Leader在負責(zé)進行消息廣播，那么新加入的服務(wù)器就會自覺進入數(shù)據(jù)恢復(fù)模式，找到Leader，并與其進行數(shù)據(jù)同步，然后一起參與到消息廣播流程中去。
?
Leader在接收到客戶端的事務(wù)請求后，會生成對應(yīng)的Proposal并發(fā)起一輪廣播協(xié)議；而如果集群中的其他機器接收到客戶端的事務(wù)請求，那么這些非Leader服務(wù)器會首先將這個事務(wù)請求轉(zhuǎn)發(fā)給Leader。
?
當(dāng)Leader崩潰或機器重啟，或者集群中已經(jīng)不存在過半的服務(wù)器與該Leader保持正常通信時，那么在重新開始新一輪的原子廣播操作之前，所有進程首先會使用崩潰恢復(fù)協(xié)議來使彼此達到一個一致的狀態(tài)，于是整個ZAB流程就會從消息廣播模式進入到崩潰恢復(fù)模式。
?
消息廣播
消息廣播使用了一個原子廣播協(xié)議，類似于2PC。
針對客戶端的事務(wù)請求，Leader會為其生成對應(yīng)的事務(wù)Proposal，并將其發(fā)送給集群中其余所有的機器，然后再分別收集各自的選票，最后進行事務(wù)提交。
但是與2PC還是略有不同，移除了中斷事務(wù)邏輯（rollback），所有的Follower要么正常反饋Leader提出的Proposal，要么就拋棄Leader；并且可以在過半的Follower已經(jīng)反饋ack時就開始提交事務(wù)Proposal了，而不需要等待所有Follower。
?
這樣簡化后的2PC是無法處理Leader崩潰而帶來的數(shù)據(jù)不一致問題的，因此在ZAB協(xié)議中添加了崩潰恢復(fù)模式來解決這個問題。
另外，整個消息廣播協(xié)議是基于具有FIFO特性的TCP協(xié)議來進行網(wǎng)絡(luò)通信的，因此能夠很容易地保證消息廣播過程中消息接收與發(fā)送的順序性。
?
在整個消息廣播過程中，Leader會為每個事務(wù)請求分配一個全局遞增的唯一ID，稱為事務(wù)ID（ZXID）。由于ZAB協(xié)議需要保證每一個消息嚴格的因果關(guān)系，因此必須將每個事務(wù)Proposal按照其ZXID的先后順序來進行排序與處理。
?
在消息廣播中，Leader會為每個Follower都各自分配一個單獨的隊列，然后將需要廣播的事務(wù)Proposal依次放入到這些隊列中，并且按照FIFO策略進行消息發(fā)送。每個Follower在接收到這個事務(wù)Proposal之后，都會首先將其以事務(wù)日志的形式寫入到本地磁盤中，并且在成功寫入后反饋給Leader一個ack。當(dāng)Leader接收到過半數(shù)的Follower的ack響應(yīng)后，就會廣播一個Commit消息給所有的Follower以通知其進行事務(wù)提交，同時Leader自身也會完成對事務(wù)的提交，而每一個Follower在接收到Commit請求后，也會完成事務(wù)的提交。
崩潰恢復(fù)
ZAB協(xié)議需要一個快速可靠的Leader選舉算法，不僅需要讓Leader自己知道自己被選舉為Leader，并且還需要讓集群中的所有其他機器也能夠快速感知到選舉產(chǎn)生的Leader服務(wù)器。
?
1）ZAB協(xié)議需要保證已經(jīng)在Leader上提交的事務(wù)最終被所有服務(wù)器都提交
?
假設(shè)一個事務(wù)在Leader上被提交了，并且已經(jīng)得到過半Follower的ack，但是在它將commit消息發(fā)送給所有Follower之前，Leader掛了。
?
2）ZAB協(xié)議需要確保丟棄那些只在Leader上被提出的事務(wù)。
假設(shè)Leader提出了一個事務(wù)Proposal之后馬上崩潰退出，從而導(dǎo)致集群中的其他服務(wù)器都沒有收到這個事務(wù)Proposal。于是，當(dāng)Leader恢復(fù)后再次加入集群中的時候，ZAB協(xié)議需要確保丟棄該事務(wù)。
?
基于以上兩個特殊情況，需要保證Leader選舉算法：能夠確保提交已經(jīng)被Leader提交的事務(wù)Proposal，同時丟棄已經(jīng)被跳過的事務(wù)Proposal。
如果讓Leader選擇算法能夠保證新選舉出來的Leader擁有集群中所有機器最高編號（ZXID最大）的事務(wù)Proposal，那么就可以保證這個新選舉出來的Leader一定具有所有已經(jīng)提交Proposal，并且可以省去Leader服務(wù)器檢查Proposal的提交和丟棄工作的這一步操作了。
Leader選舉
術(shù)語：SID 服務(wù)器ID
ZXID 事務(wù)ID，唯一標(biāo)識一次服務(wù)器狀態(tài)的變更
Vote 投票 當(dāng)集群中的機器發(fā)現(xiàn)自己無法檢測到Leader時，就會開始嘗試進行投票
Quorum 過半機器數(shù) 如果總機器數(shù)為n，那么Quorum為n/2+1
?
進入Leader選舉
當(dāng)Zookeeper集群中的一臺服務(wù)器出現(xiàn)以下兩種情況之一時，就會開始進入Leader選舉：
1）服務(wù)器 初始化
2）服務(wù)器運行時無法和Leader保持連接
?
而當(dāng)一臺機器進入Leader選舉時，當(dāng)前集群也可能處于以下兩種狀態(tài)：
1）集群中本來存在Leader
2）集群中不存在Leader
?
1）中通常是集群中的某一臺機器啟動比較晚，在它啟動之前，集群已經(jīng)可以正常工作，即已經(jīng)存在了一臺Leader服務(wù)器。針對這種情況，當(dāng)該機器試圖去選舉Leader時，會被告知當(dāng)前服務(wù)器的Leader，對于該機器來說，僅僅需要和Leader機器建立起連接，并進行狀態(tài)同步即可。
?
第一次投票
通常有兩種情況會導(dǎo)致集群中不存在Leader，一種情況是在整個服務(wù)器剛剛初始化情況時，此時尚未產(chǎn)生Leader；另一種情況是Leader宕機。
此時，集群中的所有機器都處于一種試圖選舉出一個Leader的狀態(tài)，這種狀態(tài)稱為Looking。當(dāng)一臺機器處于Looking狀態(tài)時，那么它就會向集群中的所有其他機器發(fā)送消息，這個消息稱為投票。
?
投票可以表示為（SID，ZXID），SID是所推舉的服務(wù)器唯一ID，ZXID是事務(wù)ID。
在第一次投票時，由于還無法檢測到集群中其他機器的狀態(tài)信息，因此每臺機器都是將自己作為被推舉的對象來進行投票。
第二次投票
集群中的每臺機器發(fā)出自己的投票后，也會收到來自集群中其他機器的投票。每臺機器都會根據(jù)一定的規(guī)則，來處理收到的其他機器的投票，并以此來決定是否需要變更自己的投票。
vote_sid：接收到的投票中所推舉的Leader的SID
vote_zxid：接收到的投票中所推舉的Leader的ZXID
self_sid：當(dāng)前服務(wù)器自己的SID
self_zxid：當(dāng)前服務(wù)器自己的ZXID
?
對于每次收到的投票的處理，都是一個對（vote_sid,vote_zxid）和（self_sid,self_zxid）的對比的過程。
規(guī)則1：如果vote_zxid大于self_zxid，那么認可當(dāng)前收到的投票，并再次將該投票發(fā)送出去
規(guī)則2：如果vote_zxid等于self_zxid，則就對比兩者的SID。如果vote_sid大于self_sid，那么就認可當(dāng)前接收到的投票，并再次將該投票發(fā)送出去
規(guī)則3：如果vote_zxid等于self_zxid，并且vote_sid小于self_sid，那么同樣堅持自己的投票，不做變更。
確定Leader
經(jīng)過第二次投票后，集群中的每臺機器都會再次受到其他機器的投票，然后開始統(tǒng)計投票。如果一臺機器收到超過半數(shù)的相同的投票，那么整個投票對應(yīng)的SID機器即為Leader。
小結(jié)
哪臺機器上的數(shù)據(jù)越新，那么越有可能成為Leader。數(shù)據(jù)越新，ZXID就越大，也就越能保證數(shù)據(jù)的恢復(fù)。如果幾臺服務(wù)器有著相同的ZXID，那么SID較大的服務(wù)器成為Leader。
數(shù)據(jù)同步
完成Leader選舉之后，在接收客戶端事務(wù)請求前，Leader會確認事務(wù)日志中的所有Proposal是否已經(jīng)被集群中過半的機器提交了，即是否完成數(shù)據(jù)同步。
?
正常情況下：Leader會為每一個Follower都準(zhǔn)備一個隊列，并將那些沒有被各Follow同步的事務(wù)以Proposal消息的形式逐個發(fā)送給Follower，并在每一個Proposal消息后面緊接著再發(fā)送一個Commit消息，以表示該事務(wù)已經(jīng)被提交。等到Follower將所有尚未同步的事務(wù)Proposal都從Leader上同步過來并成功應(yīng)用到本地數(shù)據(jù)庫中，Leader就會將該Follower加入到真正的可用Follower列表中。
?
如何處理需要被丟棄的Proposal的？
ZXID是一個64位的數(shù)字，低32位是一個單調(diào)遞增的計數(shù)器，針對客戶端的每一個事務(wù)請求，Leader在產(chǎn)生一個新事務(wù)Proposal的時候，都會對該計數(shù)器進行加一操作；高32位則代表了Leader周期epoch編號，每當(dāng)選舉產(chǎn)生一個新的Leader，就會從這個Leader上取出其本地日志中最大事務(wù)Proposal的ZXID，并從該ZXID中解析出epoch，然后再對其進行加一操作，之后就會以此編號作為新的epoch，并將低32位置0來開始新的ZXID。ZAB協(xié)議中這一通過epoch編號來區(qū)分Leader周期變化的策略，能夠避免不同的Leader錯誤地使用相同的ZXID編號提出不一樣的事務(wù)Proposal的異常情況，這對于識別Leader崩潰恢復(fù)前后生成的Proposal非常有幫助。
?
當(dāng)一個包含了上一個Leader周期中尚未提交過的事務(wù)Proposal的服務(wù)器啟動時，其肯定無法成為Leader，因為當(dāng)前集群中一定包含一個Quorum集合（存在過半的處于UP狀態(tài)的進程的進程子集），該集合中的機器一定包含了更高epoch的事務(wù)Proposal，因此這臺機器的事務(wù)Proposal一定不是最高，也就無法成為Leader了。當(dāng)這臺機器加入到集群后，以Follower的角色連接上Leader后，leader會根據(jù)自己服務(wù)器上最后被提交的Proposal來與Follower的Proposal進行對比，對比的結(jié)果當(dāng)然是Leader要求Follower進行一個回退操作——回退到一個已經(jīng)被集群中過半機器提交的最新的事務(wù)Proposal。
?
與Paxos算法的聯(lián)系與區(qū)別
ZAB協(xié)議并不是一個Paxos算法的典型實現(xiàn)。
聯(lián)系：
?
區(qū)別：
Paxos算法中，一個新Leader會進行兩個階段的工作。第一階段被稱為讀階段，Leader與所有其他機器進行通信來收集上一個Leader的Proposal，并將它們提交；第二階段被稱為寫階段，Leader開始提出自己的提案。
ZAB協(xié)議中，在Paxos基礎(chǔ)上增加了一個數(shù)據(jù)同步階段。在同步階段之前，ZAB也存在一個類似于Paxos讀階段的過程，稱為發(fā)現(xiàn)階段。在同步階段中，新的Leader會確保過半的Follower已經(jīng)提交了之前Leader周期中的所有事務(wù)Proposal，該階段可以保證Leader在新的周期提出Proposal之前，所有機器都已經(jīng)完成對之前所有事務(wù)Proposal的提交。一旦完成同步階段后，那么ZAB就會執(zhí)行和Paxos算法類似的寫階段。
?
本質(zhì)區(qū)別是設(shè)計目標(biāo)不一樣，ZAB主要用于構(gòu)建一個高可用的分布式數(shù)據(jù)主備系統(tǒng)，Paxos則用于構(gòu)建一個分布式的一致性狀態(tài)機系統(tǒng)。
?
典型應(yīng)用
發(fā)布訂閱（配置管理）
客戶端向服務(wù)器注冊自己需要關(guān)注的節(jié)點，一旦該節(jié)點的數(shù)據(jù)發(fā)生變更，那么客戶端就會向響應(yīng)的客戶端發(fā)送Watcher時間通知，客戶端接收到這個事件通知之后，需要主動到服務(wù)端獲取最新的數(shù)據(jù)。
如果將配置信息存放到Zookeeper上進行集中管理，那么通常情況下，應(yīng)用在啟動的時候都會主動到Zookeeper服務(wù)端上進行一次配置信息的獲取，同時，在指定節(jié)點上注冊一個Watcher監(jiān)聽，這樣的話，如果配置信息發(fā)生變更，服務(wù)端都會實時通知到所有訂閱的客戶端，從而達到獲取最新配置信息的目的。
命名服務(wù)（軟負載中心）
被命名的實體可以是集群中的機器、提供的服務(wù)地址或遠程對象。
?
比如RPC的服務(wù)注冊查找中心，ZK客戶端與ZK服務(wù)器保持連接，連接ZK服務(wù)器時RPCServer將自己的IP地址、端口號告訴ZKServer，在ZKServer上創(chuàng)建節(jié)點。RPCClient也連接ZK服務(wù)器，獲取RPCServer的地址（軟件負載均衡），并注冊Watcher。假如RPCServer掛掉，與ZK服務(wù)器的連接斷開，那么臨時節(jié)點會被刪除，此時會通知RPCClient，RPCClient可以重新選擇RPCServer進行連接。
?
并且ZK還可以創(chuàng)建全局唯一ID，基于ZK提供的創(chuàng)建節(jié)點時使用SEQUENTIAL屬性（順序節(jié)點）。
集群管理
希望知道當(dāng)前集群中有哪些集群在工作；
對集群中每天機器的運行時狀態(tài)進行數(shù)據(jù)收集；
對集群中機器進行上下線通知
?
基于ZK提供的臨時節(jié)點和Watcher監(jiān)聽特性，可以實現(xiàn)另一種集群機器存活性監(jiān)控的系統(tǒng)。
比如云主機管理，每臺機器上線后，啟動機器上的Agent，向ZK的指定節(jié)點進行注冊（臨時節(jié)點），此時監(jiān)控中心會接收到子節(jié)點變更事件，即上線通知，于是可以對這個新加入的機器開啟相應(yīng)的后臺管理邏輯。另一方面，監(jiān)控中心同樣可以獲取到機器下線的通知。
?
除了要對機器的在線狀態(tài)進行檢測，還要對機器的運行時狀態(tài)進行監(jiān)控。在運行的過程中，Agent會定時將主機的運行狀態(tài)寫入ZK上的主機節(jié)點，監(jiān)控中心提供訂閱這些節(jié)點的數(shù)據(jù)變更通知來間接地獲取主機的運行時信息。
Master選舉
在分布式系統(tǒng)中，Master往往用來協(xié)調(diào)集群中的其他系統(tǒng)單元，具有對分布式系統(tǒng)狀態(tài)變更的決定權(quán)。
場景：集群中的所有系統(tǒng)單元都需要對某個業(yè)務(wù)提供數(shù)據(jù)，但計算該數(shù)據(jù)的代價相當(dāng)大，于是只希望一臺機器或某幾臺機器來執(zhí)行該任務(wù)，集群中的其他機器共享其計算結(jié)果。
那么怎么選擇機器呢？Master選舉
一種方案是所有機器都向關(guān)系數(shù)據(jù)庫插入某條數(shù)據(jù)，主鍵都是一樣的，誰插入成功，誰就是Master。但是無法感知Master掛掉的這種情形。
而ZK的強一致性可以保證在分布式高并發(fā)情況下節(jié)點的創(chuàng)建一定能夠保證全局唯一性，即ZK將會保證客戶端無法重復(fù)創(chuàng)建一個已經(jīng)存在的數(shù)據(jù)節(jié)點（某個path下的節(jié)點名是唯一的）。只有一個客戶端能夠成功創(chuàng)建這個節(jié)點，那么這個客戶端所在機器就成為了Master。同時，其他沒有在ZK上成功創(chuàng)建結(jié)點的客戶端，都會在該節(jié)點的父節(jié)點上注冊一個子節(jié)點變更的Watcher，用于監(jiān)控當(dāng)前的Master機器是否存活，一旦發(fā)現(xiàn)當(dāng)前的Master掛了，那么其余的客戶端將會重新進行Mater選舉。
分布式鎖
可以采用數(shù)據(jù)庫的鎖，只是數(shù)據(jù)庫的性能很差。
排他鎖
可以將一個數(shù)據(jù)節(jié)點（比如/exclusive_lock/lock）視為一個鎖，所有客戶端去創(chuàng)建該節(jié)點，創(chuàng)建成功的客戶端就獲得了這個鎖。
如果獲得鎖的機器宕機，或者執(zhí)行完業(yè)務(wù)邏輯后，都會將該節(jié)點刪除。
無論什么情況下刪除了該節(jié)點，都會通知所有在該節(jié)點（/exclusive_lock）上注冊了監(jiān)聽子節(jié)點變更的Watcher的機器，這些機器在接收到通知后，會再次重新發(fā)起分布式鎖的獲取。
共享鎖
同樣是將數(shù)據(jù)節(jié)點視為一個鎖，只是這里的數(shù)據(jù)節(jié)點是一個順序節(jié)點，比如/shared_lock/{host_name}-請求類型-序列號。
獲取鎖時所有客戶端都會到/shared_lock這個節(jié)點下面創(chuàng)建一個順序節(jié)點，讀請求的話，請求類型為R（寫的話為W）。
共享鎖的定義是可以有讀讀，但不能有讀寫、寫寫、寫讀。
1、創(chuàng)建完節(jié)點后，獲取/shared_lock節(jié)點下的所有子節(jié)點，并對該節(jié)點注冊了子節(jié)點變更的Watcher監(jiān)聽。
2、確定自己的節(jié)點序號在所有子節(jié)點中的順序
3、對于讀請求：如果沒有比自己序號小的子節(jié)點，或者所有比自己序號小的節(jié)點都是讀請求，那么表示自己已經(jīng)獲得了共享鎖；如果比自己序號小的子節(jié)點中有寫請求，那么就需要進入等待。
對于寫請求：如果自己不是序號最小的子節(jié)點，那么就需要進入等待
4、接收到Watcher通知后，重復(fù)步驟1
?
釋放鎖時就直接將自己的節(jié)點刪除即可。
高可用
Zookeeper集群服務(wù)器數(shù)推薦為奇數(shù)。由于過半存活即可用特性，3臺機器掛掉一臺仍可用。而5臺和6臺服務(wù)器在掛掉兩臺后仍可用，掛掉三臺都均不可用，因此5臺和6臺服務(wù)器在其容災(zāi)能力上是沒有區(qū)別的，因此Zookeeper集群推薦部署為奇數(shù)臺服務(wù)器。
總結(jié)
以上是生活随笔為你收集整理的持续更新的Zookeeper知识总结的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： Java的IO总结
- 下一篇： leetcode279 完全平方数