今天就跟大家聊聊有關(guān)怎么解析zookeeper 原理，可能很多人都不太了解，為了讓大家更加了解，小編給大家總結(jié)了以下內(nèi)容，希望大家根據(jù)這篇文章可以有所收獲。
讓客戶滿意是我們工作的目標(biāo)，不斷超越客戶的期望值來自于我們對這個行業(yè)的熱愛。我們立志把好的技術(shù)通過有效、簡單的方式提供給客戶，將通過不懈努力成為客戶在信息化領(lǐng)域值得信任、有價值的長期合作伙伴，公司提供的服務(wù)項目有：域名與空間、網(wǎng)站空間、營銷軟件、網(wǎng)站建設(shè)、蓬安網(wǎng)站維護、網(wǎng)站推廣。
1. 領(lǐng)導(dǎo)者（leader）: 負(fù)責(zé)進行投票的發(fā)起和決議，更新系統(tǒng)狀態(tài)。
2. 學(xué)習(xí)者（learner）: 包括跟隨者是（follower）和觀察者（observer）。
3. 跟隨者（follower）: 用于接受客戶端的請求并向客戶端返回結(jié)果，在選主的過程中參與投票。
4. 觀察者（observer）: 可以接受客戶端連接，將寫入請求轉(zhuǎn)發(fā)給leader，但observer不參加投票過程，只同步leader的狀態(tài)，observer的目的是為了擴展系統(tǒng)，提高讀取速度。
5. 客戶端（client）: 請求發(fā)起方。
Zookeeper的核心是原子廣播，這個機制保證了各個Server之間的同步。實現(xiàn)這個機制的協(xié)議叫做Zab協(xié)議。Zab協(xié)議有兩種模式，它們分別是回復(fù)模式（選主）和廣播模式（同步）。當(dāng)服務(wù)啟動或者領(lǐng)導(dǎo)者崩潰后，Zab就進入恢復(fù)模式，當(dāng)領(lǐng)導(dǎo)者被選舉出來，且大多數(shù)Server完成了和leader的狀態(tài)同步以后，恢復(fù)模式就結(jié)束了。狀態(tài)同步保證了leader和Server具有相同的系統(tǒng)狀態(tài)。
為了保證事務(wù)的順序一致性，zookeeper采用了遞增的事務(wù)id號（zxid）來標(biāo)識事務(wù)。所有的提議（proposal）都在被提出的時候加上zxid。實現(xiàn)中zxid是一個64位的數(shù)字，它高32位是epoch用來標(biāo)識leader關(guān)系是否改變，每次一個leader被選出來，它都會有一個新的epoch，標(biāo)識當(dāng)前屬于哪個leader的統(tǒng)治時期。低32位用于遞增計數(shù)。
每個Server工作過程中有三個狀態(tài)：
LOOKING : 當(dāng)前Server不知道leader是誰，正在搜尋。
LEADING : 當(dāng)前Server即為選出來的leader。
FOLLOWING : leader已經(jīng)選舉出來，當(dāng)前Server與之同步。
假設(shè)有五臺服務(wù)器組成的Zookeeper集群，它們的id從1-5，同時它們都是最新啟動的，也就是沒有歷史數(shù)據(jù)，在存放數(shù)據(jù)量這一點上，都是一樣的。假設(shè)這些服務(wù)器依序啟動，來看看會發(fā)生什么，如圖所示。
1. 服務(wù)器1啟動，此時只有它一臺服務(wù)器啟動了，它發(fā)出去的報文沒有任何響應(yīng)，所以它的選舉狀態(tài)一直是LOOKING狀態(tài)。
2. 服務(wù)器2啟動，它與最開始啟動的服務(wù)器1進行通信，互相交換自己的選舉結(jié)果，由于兩者都沒有歷史數(shù)據(jù)，所以id值較大的服務(wù)器2勝出，但是由于沒有達(dá)到超過半數(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，所以它只能接收當(dāng)小弟的命了。
5. 服務(wù)器5啟動，同4一樣當(dāng)小弟。
[zk: 127.0.0.1:2181(CONNECTED) 2] get /20181112 hello #數(shù)據(jù) cZxid = 0x4 #創(chuàng)建節(jié)點的事務(wù)zxid ctime = Mon Nov 12 15:31:17 CST 2018 #創(chuàng)建時間 mZxid = 0x4 #最后一次更新的事務(wù)zxid mtime = Mon Nov 12 15:31:17 CST 2018 #最后一次更新時間 pZxid = 0x4 #最后一次更新子節(jié)點zxid cversion = 0 #子節(jié)點變化號，znode子節(jié)點修改次數(shù) dataVersion = 0 #數(shù)據(jù)變化版本號 aclVersion = 0 #訪問控制列表的變化號 ephemeralOwner = 0x0 #如果是臨時節(jié)點，這個是znode擁有者的session id。如果不是臨時節(jié)點則是0。 dataLength = 5 #數(shù)據(jù)長度 numChildren = 0 #子節(jié)點數(shù)量
Znode有兩種類型，短暫的（ephemeral）和 持久的（persistent）。
Znode的類型在創(chuàng)建時確定并且之后不能修改。
短暫Znode的客戶端會話結(jié)束時，zookeeper會將該短暫znode刪除，短暫znode不可以有子節(jié)點。
持久Znode不依賴于客戶端會話，只有當(dāng)客戶端明確要刪除該持有化Znode時才會刪除。
Znode有四種形式的目錄節(jié)點
PERSISITENT
EPHEMERAL
PERSISITENT_SEQUENTIAL
EPHEMERAL_SEQUENTIAL
1. Client 向 ZooKeeper 的 Server1 上寫數(shù)據(jù)，發(fā)送一個寫請求。
2. 如果Server1不是Leader，那么Server1 會把接受到的請求進一步轉(zhuǎn)發(fā)給Leader，因為每個ZooKeeper的Server里面有一個是Leader。這個Leader 會將寫請求廣播給各個Server，比如Server1和Server2，各個Server寫成功后就會通知Leader。
3. 當(dāng)Leader收到大多數(shù) Server 數(shù)據(jù)寫成功了，那么就說明數(shù)據(jù)寫成功了。如果這里三個節(jié)點的話，只要有兩個節(jié)點數(shù)據(jù)寫成功了，那么就認(rèn)為數(shù)據(jù)寫成功了。寫成功之后，Leader會告訴Server1數(shù)據(jù)寫成功了。
4. Server1會進一步通知 Client 數(shù)據(jù)寫成功了，這時就認(rèn)為整個寫操作成功。
Watcher 在 Zookeeper 是一個核心功能，Watcher可以監(jiān)控目錄節(jié)點的數(shù)據(jù)變化以及子目錄的變化，一單這些狀態(tài)發(fā)生變化，服務(wù)器就會通知所有設(shè)置在這個目錄節(jié)點上的Watcher，從而每個客戶端都很快知道它所關(guān)注的狀態(tài)發(fā)生變化，而做出相應(yīng)的反應(yīng)。
可以設(shè)置觀察的操作：exists、getChildren、getData
可以出發(fā)觀察的操作：create、delete、setData
監(jiān)聽原理詳解：
1. 首先要有一個main()線程
2. 在main線程中創(chuàng)建Zookeeper客戶端，這時就會創(chuàng)建兩個線程，一個負(fù)責(zé)網(wǎng)絡(luò)連接通信（connet），一個負(fù)責(zé)監(jiān)聽（listener）。
3. 通過connect線程將注冊的監(jiān)聽事件發(fā)送給Zookeeper。
4. 在Zookeeper的注冊監(jiān)聽器列表中將注冊的監(jiān)聽事件添加到列表中。
5. Zookeeper監(jiān)聽到有數(shù)據(jù)或路徑變化，就會將這個消息發(fā)送給listener線程。
6. listener線程內(nèi)部調(diào)用了process（）方法。
看完上述內(nèi)容，你們對怎么解析zookeeper 原理有進一步的了解嗎？如果還想了解更多知識或者相關(guān)內(nèi)容，請關(guān)注創(chuàng)新互聯(lián)行業(yè)資訊頻道，感謝大家的支持。
重慶分公司
重慶分公司
