ZooKeeper進階原理

1. 節點類型

1. 持久節點
   Persistent Znode：創建後始終存在，除非被刪除.
2. 臨時節點
   Ephemeral Znode：臨時節點，客戶端與ZooKeeper服務斷開連接後，節點消失.
3. 序列節點
   Sequence Znode：Znode被創建時會在名稱後被賦予一個序號值，序列值由是全局維護的.
   作用：在分佈式系統中，順序號可以被用於爲所有的事件進行全局排序，這樣一來，客戶端就可以通過順序號來判斷事件執行的順序.
   上面的節點進行組合，最終可以生產4種類型的節點
   （1）持久化節點：
   除非被刪除，否則始終存在
   （2）持久化序列節點：
   帶有序號的持久化節點
   （3）臨時節點：
   客戶端與ZooKeeper服務斷開連接後，節點消失.
   （4）臨時序列節點：
   帶有序號的臨時節點
   而即使當序列節點被刪除後，被使用過的序列號，依然不會自動釋放.

2. Stat結構體

（1）czxid：創建節點的事務zxid
每次修改節點狀態都會受到一個zxid（c表示create）形式的時間戳，也就是ZooKeeper事務ID.
zxid是ZooKeeper中所有修改的總的次序，每次修改都有唯一的zxid，如果zxid1的值小於zxid2的值，那麼zxid1一定在zxid2之前被執行.
（2）ctime：被創建的毫秒數，從1970年1月1日開始.
（3）mzxid：m代表modify，最後更新的zxid
（4）mtime：最後更新的毫秒數，從1970年1月1日開始.
（5）pZxid：該節點或該節點的子節點（與孫節點無關）最後更新的zxid.
（6）cversion：znode的變化號，新建是0，以後每次更新+1.
（7）dataVersion：znode數據變化號，當調用set方法改變znode值時，版本號+1.
（8）aclVersion：znode訪問控制列表的變化號.
（9）ephemeralOwner：如果是臨時節點，這個值是擁有者的sessionID，如果不是臨時節點則是0.
（10）dataLength：數據長度
（11）numChildren：子節點數量

3. 監聽原理

（1）首先要有一個main()線程
（2）在main()線程中創建ZooKeeper客戶端，就會創建2個線程，一個負責連接通信（connect），一個負責監聽（listener）
（3）通過connect線程，註冊的監聽事件會被髮送給ZooKeeper
（4）ZooKeeper會將註冊的監聽事件添加到註冊監聽器列表中.
（5）一旦ZooKeeper監聽到路徑或者數據有所變化時，就會將整個消息發給listener線程
（6）listener線程會調用process()方法
常見的監聽：

1. 監聽節點數據的變化

get path [watch]

2. 監聽子節點增減的變化

ls path [watch]

4. 選舉機制

1. 半數機制：集羣中半數以上的機器存活，集羣可用.所以ZooKeeper適合奇數臺的集羣.
2. ZooKeeper雖然沒有像HDFS一樣，指定Master和Slave，這樣的主從關係，但是ZooKeeper工作時，會有一個Leader，其他節點爲Follower，這個Leader是由內部選舉機制產生的.
   
   假設，上面的Server1~Server5都是以此新啓動的，上面並沒有任何數據.會發生下面一系列狀況：
   （1）Server1啓動，進行Leader選舉，給自己投了1票，此時，Server1只有1票，沒有達到半數以上（3票），不能當選爲Leader，進入LOOKING狀態.
   （2）Server2啓動，也給自己投了1票.發現Server1是LOOKING狀態，這時會交換選票信息，此時Server1發現，雖然zxid相同，但Server2的myid比自己大，於是改選Server2爲Leader，此時Server2得到2票，依然沒有達到半數以上，Server1與Server2都進入LOOKING狀態.
   （3）Server3啓動，也給自己投了1票.發現Server1和Server2都是LOOKING狀態，於是，他們三個開始交換選票信息，最後發現，zxid都相同，但是Server3的myid最大，於是Server1和Server2都改選Server3爲Leader，這時Server3得到3票，超過半數，此時它當選爲Leader狀態變爲LEADING，Server1和Server2成爲Follower，狀態變爲FOLLOWING.
   （4）Server4啓動，先投自己1票再說，然後發現Server1~Server3不在LOOKING狀態，所以它們不會再改變選擇結果，那麼Server4少數服從多數，也改選Server3，自己變成Follower，狀態改爲FOLLOWING.
   （5）Server5同Server4一樣，成爲了Follower，狀態爲FOLLOWING.

5. 寫數據流程

（1）client連接到Server1，向其發起寫請求.
（2）Server1不是Leader，所以會將接收到的寫請求轉發給Leader
（3）Leader接受到寫請求後，將請求廣播（broadcast）給包集羣中的所有Server
（4）當集羣中的Server接收到Leader廣播的請求後，在待寫列表中添加此任務.並返回成功狀態給Leader
（5）Leader接收到半數以上所返回的成功狀態則認爲任務成功被集羣接收，此時下達提交命令.
（6）集羣開始將待寫列表中的那個任務進行提交，待提交成功結束後，返回給Leader成功狀態.
（7）Leader接收到半數以上成功的回覆時，判定寫操作成功，將結果通知給Server1.
（8）Server1接收到來自Leader的通知後，再對發起寫請求的Client返回操作結果信息.