尚硅谷大數據技術之Zookeeper第3章Zookeeper內部原理

3.1 選舉機制

1）半數機制（Paxos 協議）：集羣中半數以上機器存活，集羣可用。因此zookeeper適合裝在奇數臺機器上。

2）Zookeeper雖然在配置文件中並無指定master和slave。可是，zookeeper工做時，是有一個節點爲leader，其餘則爲follower，Leader是經過內部的選舉機制臨時產生的

3）以一個簡單的例子來講明整個選舉的過程。

假設有五臺服務器組成的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同樣當小弟。

3.2 節點類型

1）Znode有兩種類型：

短暫（ephemeral）：客戶端和服務器端斷開鏈接後，建立的節點本身刪除

持久（persistent）：客戶端和服務器端斷開鏈接後，建立的節點不刪除

2）Znode有四種形式的目錄節點（默認是persistent ）

（1）持久化目錄節點（PERSISTENT）

客戶端與zookeeper斷開鏈接後，該節點依舊存在

（2）持久化順序編號目錄節點（PERSISTENT_SEQUENTIAL）

客戶端與zookeeper斷開鏈接後，該節點依舊存在，只是Zookeeper給該節點名稱進行順序編號

（3）臨時目錄節點（EPHEMERAL）

客戶端與zookeeper斷開鏈接後，該節點被刪除

（4）臨時順序編號目錄節點（EPHEMERAL_SEQUENTIAL）

客戶端與zookeeper斷開鏈接後，該節點被刪除，只是Zookeeper給該節點名稱進行順序編號

3）建立znode時設置順序標識，znode名稱後會附加一個值，順序號是一個單調遞增的計數器，由父節點維護

4）在分佈式系統中，順序號能夠被用於爲全部的事件進行全局排序，這樣客戶端能夠經過順序號推斷事件的順序

3.3 stat結構體

1）czxid- 引發這個znode建立的zxid，建立節點的事務的zxid

每次修改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.4 監聽器原理

1）監聽原理詳解：

1）首先要有一個main()線程

2）在main線程中建立Zookeeper客戶端，這時就會建立兩個線程，一個負責網絡鏈接通訊（connet），一個負責監聽（listener）。

3）經過connect線程將註冊的監聽事件發送給Zookeeper。

4）在Zookeeper的註冊監聽器列表中將註冊的監聽事件添加到列表中。

5）Zookeeper監聽到有數據或路徑變化，就會將這個消息發送給listener線程。

6）listener線程內部調用了process（）方法。

2）常見的監聽

（1）監聽節點數據的變化：

get path [watch]

（2）監聽子節點增減的變化

ls path [watch]

3.5 寫數據流程

ZooKeeper 的寫數據流程主要分爲如下幾步：

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 數據寫成功了，這時就認爲整個寫操做成功。ZooKeeper 整個寫數據流程就是這樣的。

 

本教程由尚硅谷教育大數據研究院出品，如需轉載請註明來源，歡迎你們關注尚硅谷公衆號（atguigu）瞭解更多。