Zookeeper是Apache開源的一個分布式框架，它主要為分布式應用提供協調服務，
Zookeeper主要負責存盤和管理大家都關心的資料，一旦這些資料的狀態發生變化，Zookeeper就會通知那些注冊在Zookeeper上的服務，簡單來講就是zookeeper=檔案系統+通知機制，
一 Zookeeper的資料結構
Zookeeper的資料結構與Unix檔案系統很類似，整體上可以看作是一棵樹，與Unix檔案系統不同的是Zookeeper的每個節點都可以存放資料，每個節點稱作一個ZNode，默認存盤1MB的資料，每個ZNode都可以通過其路徑唯一標識，
1.1 四種型別的ZNode
- 持久化目錄節點：客戶端與Zookeeper斷開連接后，該節點依舊存在，
- 持久化順序編號目錄節點：客戶端與Zookeeper斷開連接后，該節點依舊存在，只是Zookeeper給該節點名稱就行順序編號，
- 臨時目錄節點：客戶端與Zookeeper斷開連接后，該節點被洗掉，
- 臨時順序編號目錄節點：客戶端與Zookeeper斷開連接后，該節點被洗掉，只是Zookeeper給該節點名稱就行順序編號，
說明：創建ZNode時設定順序標識，ZNode名稱后會附加一個值，順序號是一個單調遞增的計數器，由父節點維護，
1.2 stat結構體
ZNode主要包含以下資訊：
- czxid-創建節點的事務 zxid：
每次修改 ZooKeeper 狀態都會收到一個 zxid 形式的時間戳，也就是 ZooKeeper 事務 ID，
事務 ID 是 ZooKeeper 中所有修改總的次序，每個修改都有唯一的 zxid，如果 zxid1 小于 zxid2，那么 zxid1 在 zxid2 之前發生，
- ctime ：znode 被創建的毫秒數(從 1970 年開始)
- mzxid：znode 最后更新的事務 zxid
- mtime：znode 最后修改的毫秒數(從 1970 年開始)
- pZxid：znode 最后更新的子節點 zxid
- cversion：znode 子節點變化號，znode 子節點修改次數
- dataversion：znode 資料變化號
- aclVersion：znode 訪問控制串列的變化號
- ephemeralOwner：如果是臨時節點，這個是 znode 擁有者的 session id，如果不是臨時節
點則是 0
- dataLength：znode 的資料長度
- numChildren：znode 子節點數量
二 Zookeeper的應用場景
Zookeeper的主要應用場景有統一命名服務，統一配置管理，統一集群管理，服務器節點動態上下線等，
2.1 統一命名服務
在分布式環境中，經常需要對服務進行統一命名，假如有一個服務部署了2兩個副本，直接呼叫具體的服務肯定有些不合適，因為我們并不清楚哪個服務可以更快的處理我們的請求，這時候我們可以將這三個服務進行統一命名，然后其內部再去負載，這樣就可以呼叫最優的那個服務了，
2.2 統一配置管理
分布式環境下，組態檔的同步可以由Zookeeper來實作，
- 將組態檔寫入Zookeeper的一個ZNode
- 各個客戶端服務監聽這個ZNode
- 一旦ZNode發生改變，Zookeeper將通知各個客戶端服務
2.3 統一集群管理
Zookeeper可以實作實時監控節點狀態變化，當有一個三個節點的服務，假如其他一個宕機了，其他兩個節點可立即收到訊息，實作實時監控，將這三個節點寫入Zookeeper的一個ZNode，每個節點都去監聽這個ZNode，當ZNode發生變化時，這些節點可實時收到變化狀態，
監聽器的原理
- 創建一個Main()執行緒
- 在Main()執行緒中創建兩個執行緒，一個負責網路連接通信（connect），一個負責監聽（listener）
- 通過connect執行緒將注冊的監聽事件發送給Zookeeper
- 將注冊的監聽事件添加到Zookeeper的注冊監聽器串列中
- Zookeeper監聽到有資料或路徑發生變化時，把這條訊息發送給Listener執行緒
- Listener執行緒內部呼叫process()方法
三 Zookeeper集群
Zookeeper集群雖然沒有指定Master和Slave，但是，在Zookeeper作業時，會通過內部選舉機制產生一個Leader節點，其他節點為Follower或者是Observer，
被宣告為Observer的節點，不參與選舉程序，也不參與寫操作的”過半寫成功“策略，
過半寫成功策略：Leader節點接收到寫請求后，這個Leader會將寫請求廣播給各個server，各個server會將該寫請求加入待寫佇列，并向Leader發送成功資訊，當Leader收到一半以上的成功訊息后，說明該寫操作可以執行，Leader會向各個server發送提交訊息，各個server收到訊息后開始寫，
Follower和Observer只提供資料的讀操作，當他們接收的寫請求時，會將該請求轉發給Leader節點，
集群中只要有半數以上的節點存活，Zookeeper集群就能正常服務，因此Zookeeper集群適合安裝奇數臺機器，
3.1 選舉機制
（1）服務器 1 啟動，發起一次選舉，服務器 1 投自己一票，此時服務器 1 票數一票，不夠半數以上（3 票），選舉無法完成，服務器 1 狀態保持為 LOOKING；
（2）服務器 2 啟動，再發起一次選舉，服務器 1 和 2 分別投自己一票并交換選票資訊：此時服務器 1 發現服務器 2 的 ID 比自己目前投票推舉的（服務器 1）大，更改選票為推舉服務器 2，此時服務器 1 票數 0 票，服務器 2 票數 2 票，沒有半數以上結果，選舉無法完成，服務器 1，2 狀態保持 LOOKING；
（3）服務器 3 啟動，發起一次選舉，此時服務器 1 和 2 都會更改選票為服務器 3，此次投票結果：服務器 1 為 0 票，服務器 2 為 0 票，服務器 3 為 3 票，此時服務器 3 的票數已經超過半數，服務器 3 當選 Leader，服務器 1，2 更改狀態為 FOLLOWING，服務器 3 更改狀態為 LEADING；
（4）服務器 4 啟動，發起一次選舉，此時服務器 1，2，3 已經不是 LOOKING 狀態，不會更改選票資訊，交換選票資訊結果：服務器 3 為 3 票，服務器 4 為 1 票，此時服務器 4服從多數，更改選票資訊為服務器 3，并更改狀態為 FOLLOWING；
（5）服務器 5 啟動，同 4 一樣當小弟，
轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/43147.html
標籤：Java