溫馨提示×
您好，登錄后才能下訂單哦！
點擊 登錄注冊 即表示同意《億速云用戶服務條款》
您好，登錄后才能下訂單哦！
今天就跟大家聊聊有關怎么解析zookeeper 原理，可能很多人都不太了解，為了讓大家更加了解，小編給大家總結了以下內容，希望大家根據這篇文章可以有所收獲。
1. 領導者（leader）: 負責進行投票的發起和決議，更新系統狀態。
2. 學習者（learner）: 包括跟隨者是（follower）和觀察者（observer）。
3. 跟隨者（follower）: 用于接受客戶端的請求并向客戶端返回結果，在選主的過程中參與投票。
4. 觀察者（observer）: 可以接受客戶端連接，將寫入請求轉發給leader，但observer不參加投票過程，只同步leader的狀態，observer的目的是為了擴展系統，提高讀取速度。
5. 客戶端（client）: 請求發起方。
Zookeeper的核心是原子廣播，這個機制保證了各個Server之間的同步。實現這個機制的協議叫做Zab協議。Zab協議有兩種模式，它們分別是回復模式（選主）和廣播模式（同步）。當服務啟動或者領導者崩潰后，Zab就進入恢復模式，當領導者被選舉出來，且大多數Server完成了和leader的狀態同步以后，恢復模式就結束了。狀態同步保證了leader和Server具有相同的系統狀態。
為了保證事務的順序一致性，zookeeper采用了遞增的事務id號（zxid）來標識事務。所有的提議（proposal）都在被提出的時候加上zxid。實現中zxid是一個64位的數字，它高32位是epoch用來標識leader關系是否改變，每次一個leader被選出來，它都會有一個新的epoch，標識當前屬于哪個leader的統治時期。低32位用于遞增計數。
每個Server工作過程中有三個狀態：
LOOKING : 當前Server不知道leader是誰，正在搜尋。
LEADING : 當前Server即為選出來的leader。
FOLLOWING : leader已經選舉出來，當前Server與之同步。
假設有五臺服務器組成的Zookeeper集群，它們的id從1-5，同時它們都是最新啟動的，也就是沒有歷史數據，在存放數據量這一點上，都是一樣的。假設這些服務器依序啟動，來看看會發生什么，如圖所示。
1. 服務器1啟動，此時只有它一臺服務器啟動了，它發出去的報文沒有任何響應，所以它的選舉狀態一直是LOOKING狀態。
2. 服務器2啟動，它與最開始啟動的服務器1進行通信，互相交換自己的選舉結果，由于兩者都沒有歷史數據，所以id值較大的服務器2勝出，但是由于沒有達到超過半數以上的服務器都同意選舉它(這個例子中的半數以上是3)，所以服務器1、2還是繼續保持LOOKING狀態。
3. 服務器3啟動，根據前面的理論分析，服務器3成為服務器1、2、3中的老大，而與上面不同的是，此時有三臺服務器選舉了它，所以它成為了這次選舉的Leader。
4. 服務器4啟動，根據前面的分析，理論上服務器4應該是服務器1、2、3、4中最大的，但是由于前面已經有半數以上的服務器選舉了服務器3，所以它只能接收當小弟的命了。
5. 服務器5啟動，同4一樣當小弟。
[zk: 127.0.0.1:2181(CONNECTED) 2] get /20181112 hello #數據 cZxid = 0x4 #創建節點的事務zxid ctime = Mon Nov 12 15:31:17 CST 2018 #創建時間 mZxid = 0x4 #最后一次更新的事務zxid mtime = Mon Nov 12 15:31:17 CST 2018 #最后一次更新時間 pZxid = 0x4 #最后一次更新子節點zxid cversion = 0 #子節點變化號，znode子節點修改次數 dataVersion = 0 #數據變化版本號 aclVersion = 0 #訪問控制列表的變化號 ephemeralOwner = 0x0 #如果是臨時節點，這個是znode擁有者的session id。如果不是臨時節點則是0。 dataLength = 5 #數據長度 numChildren = 0 #子節點數量
Znode有兩種類型，短暫的（ephemeral）和 持久的（persistent）。
Znode的類型在創建時確定并且之后不能修改。
短暫Znode的客戶端會話結束時，zookeeper會將該短暫znode刪除，短暫znode不可以有子節點。
持久Znode不依賴于客戶端會話，只有當客戶端明確要刪除該持有化Znode時才會刪除。
Znode有四種形式的目錄節點
PERSISITENT
EPHEMERAL
PERSISITENT_SEQUENTIAL
EPHEMERAL_SEQUENTIAL
1. Client 向 ZooKeeper 的 Server1 上寫數據，發送一個寫請求。
2. 如果Server1不是Leader，那么Server1 會把接受到的請求進一步轉發給Leader，因為每個ZooKeeper的Server里面有一個是Leader。這個Leader 會將寫請求廣播給各個Server，比如Server1和Server2，各個Server寫成功后就會通知Leader。
3. 當Leader收到大多數 Server 數據寫成功了，那么就說明數據寫成功了。如果這里三個節點的話，只要有兩個節點數據寫成功了，那么就認為數據寫成功了。寫成功之后，Leader會告訴Server1數據寫成功了。
4. Server1會進一步通知 Client 數據寫成功了，這時就認為整個寫操作成功。
Watcher 在 Zookeeper 是一個核心功能，Watcher可以監控目錄節點的數據變化以及子目錄的變化，一單這些狀態發生變化，服務器就會通知所有設置在這個目錄節點上的Watcher，從而每個客戶端都很快知道它所關注的狀態發生變化，而做出相應的反應。
可以設置觀察的操作：exists、getChildren、getData
可以出發觀察的操作：create、delete、setData
監聽原理詳解：
1. 首先要有一個main()線程
2. 在main線程中創建Zookeeper客戶端，這時就會創建兩個線程，一個負責網絡連接通信（connet），一個負責監聽（listener）。
3. 通過connect線程將注冊的監聽事件發送給Zookeeper。
4. 在Zookeeper的注冊監聽器列表中將注冊的監聽事件添加到列表中。
5. Zookeeper監聽到有數據或路徑變化，就會將這個消息發送給listener線程。
6. listener線程內部調用了process（）方法。
看完上述內容，你們對怎么解析zookeeper 原理有進一步的了解嗎？如果還想了解更多知識或者相關內容，請關注億速云行業資訊頻道，感謝大家的支持。
免責聲明：本站發布的內容（圖片、視頻和文字）以原創、轉載和分享為主，文章觀點不代表本網站立場，如果涉及侵權請聯系站長郵箱：is@yisu.com進行舉報，并提供相關證據，一經查實，將立刻刪除涉嫌侵權內容。
