大數據學習筆記之Zookeeper（三）：Zookeeper理論篇（二）

文章目錄

• 3.1 數據結構
• 3.2 節點類型
• 3.3 特色
• 3.4 選舉機制
• 3.5 stat結構體
• 3.6 監聽器原理

3.1 數據結構

ZooKeeper數據模型的結構與Unix文件系統很相似，總體上能夠看做是一棵樹，每一個節點稱作一個ZNode。
很顯然zookeeper集羣自身維護了一套數據結構。這個存儲結構是一個樹形結構，其上的每個節點，咱們稱之爲"znode"，每個znode默認可以存儲1MB的數據，每一個ZNode均可以經過其路徑惟一標識

3.2 節點類型

1）Znode有兩種類型：
短暫（ephemeral）：客戶端和服務器端斷開鏈接後，建立的節點本身刪除
持久（persistent）：客戶端和服務器端斷開鏈接後，建立的節點不刪除
2）Znode有四種形式的目錄節點（默認是persistent ）
（1）持久化目錄節點（PERSISTENT）
客戶端與zookeeper斷開鏈接後，該節點依舊存在
（2）持久化順序編號目錄節點（PERSISTENT_SEQUENTIAL）
客戶端與zookeeper斷開鏈接後，該節點依舊存在，只是Zookeeper給該節點名稱進行順序編號
若是是PERSISTENT的，須要記着本身的名字是否被用過，是否會發生和以前的節點有衝突的狀況，若是建立帶序號的，默認都會帶編號並且保證不重複。
（3）臨時目錄節點（EPHEMERAL）
客戶端與zookeeper斷開鏈接後，該節點被刪除
（4）臨時順序編號目錄節點（EPHEMERAL_SEQUENTIAL）
客戶端與zookeeper斷開鏈接後，該節點被刪除，只是Zookeeper給該節點名稱進行順序編號

3）建立znode時設置順序標識，znode名稱後會附加一個值，順序號是一個單調遞增的計數器，由父節點維護
4）在分佈式系統中，順序號能夠被用於爲全部的事件進行全局排序，這樣客戶端能夠經過順序號推斷事件的順序

3.3 特色

1）Zookeeper：一個領導者（leader），多個跟隨者（follower）組成的集羣。
2）Leader負責進行投票的發起和決議，更新系統狀態，即寫操做都是由leader來完成，讀操做都是有follower完成
3）Follower用於接收客戶請求並向客戶端返回結果，在選舉Leader過程當中參與投票
4）集羣中只要有半數以上節點存活，Zookeeper集羣就能正常服務。爲何是半數?由於偶數沒有意義，浪費了一個設備。
5）全局數據一致：每一個server保存一份相同的數據副本，client不管鏈接到哪一個server，數據都是一致的。
6）更新請求順序進行，來自同一個client的更新請求按其發送順序依次執行。
7）數據更新原子性，一次數據更新要麼成功，要麼失敗。
8）實時性，在必定時間範圍內，client能讀到最新數據。

3.4 選舉機制

1）半數機制：集羣中半數以上機器存活，集羣可用。因此zookeeper適合裝在奇數臺機器上。
2）Zookeeper雖然在配置文件中並無指定master和slave。可是，zookeeper工做時，是有一個節點爲leader，其餘則爲follower，Leader是經過內部的選舉機制臨時產生的
3）以一個簡單的例子來講明整個選舉的過程。
假設有五臺服務器組成的zookeeper集羣，它們的id從1-5，同時它們都是最新啓動的，也就是沒有歷史數據，在存放數據量這一點上，都是同樣的。假設這些服務器依序啓動，來看看會發生什麼。

（1）服務器1啓動，此時只有它一臺服務器啓動了，它發出去的報沒有任何響應，因此它的選舉狀態一直是LOOKING狀態。
（2）服務器2啓動，它與最開始啓動的服務器1進行通訊，互相交換本身的選舉結果，因爲二者都沒有歷史數據，因此id值較大的服務器2勝出，可是因爲沒有達到超過半數以上的服務器都贊成選舉它(這個例子中的半數以上是3)，因此服務器一、2仍是繼續保持LOOKING狀態。
（3）服務器3啓動，根據前面的理論分析，服務器3成爲服務器一、二、3中的老大，而與上面不一樣的是，此時有三臺服務器選舉了它，因此它成爲了此次選舉的leader。
（4）服務器4啓動，根據前面的分析，理論上服務器4應該是服務器一、二、三、4中最大的，可是因爲前面已經有半數以上的服務器選舉了服務器3，因此它只能接收當小弟的命了。
（5）服務器5啓動，同4同樣當小弟。

3.5 stat結構體

1）czxid- 引發這個znode建立的zxid，建立節點的事務的zxid（ZooKeeper Transaction Id）
每次修改ZooKeeper狀態都會收到一個zxid形式的時間戳，也就是ZooKeeper事務ID。
事務ID是ZooKeeper中全部修改總的次序。每一個修改都有惟一的zxid，若是zxid1小於zxid2，那麼zxid1在zxid2以前發生。
2）ctime - znode被建立的毫秒數(從1970年開始)
3）mzxid - znode最後更新的zxid
4）mtime - znode最後修改的毫秒數(從1970年開始)
5）pZxid-znode最後更新的子節點zxid
6）cversion - znode子節點變化號，znode子節點修改次數
7）dataversion - znode數據變化號
8）aclVersion - znode訪問控制列表的變化號
9）ephemeralOwner- 若是是臨時節點，這個是znode擁有者的session id。若是不是臨時節點則是0。
10）dataLength- znode的數據長度
11）numChildren - znode子節點數量

3.6 監聽器原理

監聽器是一個接口，咱們的代碼中能夠實現Wather這個接口，實現其中的process方法，方法中即咱們本身的業務邏輯
監聽器的註冊是在獲取數據的操做中實現：
getData(path,watch?)監聽的事件是：節點數據變化事件
getChildren(path,watch?)監聽的事件是：節點下的子節點增減變化事件