Zookeeper相關知識
一、zookeeper的特點：
1，zookeeper中存在一個leader和多個follower
2，集群中只要有半數以上的節點存活，zookeeper集群就能正常服務
3，全局數據一致：每天zookeeper的server中保存同一份相同的副本
4，更新順序性：來自同一個client的更新請求按其發送順序依次執行
5，數據原子性，一次數據更新要麼成功，要麼失敗
6，實時性：在一定時間範圍內，client能讀取到數據
二、zookeeper的選舉機制
LOOKING : 尋找Leader狀態，處於該狀態需要進入選舉流程
LEADING : 領導者狀態，表明當前角色為Leader
FOLLOWING: 跟隨者，Leader已經選舉出來,表明當前服務角色為Follower
OBSERVER: 觀察者狀態。 接收客戶端請求，將客戶端寫請求轉發給Leader，不參與投票過程，只同步Leader狀態，目的是為了擴展系統，提高讀取速度
選舉中服務器1比服務器2的大是根據:1，zxid(事務誰更靠後)；2，myid(當zxid相同就比較myid誰大)
（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一樣當小弟。
三、ZAB協議
Zookeeper的核心是原子廣播機制，這個機制保證了各個server之間的同步。實現這個機制的協議叫做Zab協議。Zab協議有兩種模式，它們分別是恢復模式和廣播模式。
(1) 恢復模式：
當服務啟動或者在領導者崩潰後，Zab就進入了恢復模式，當領導者被選舉出來，且大多數server完成了和leader的狀態同步以後，恢復模式就結束了。狀態同步保證了leader和server具有相同的系統狀態。
(2) 廣播模式：
一旦Leader已經和多數的Follower進行了狀態同步後，他就可以開始廣播消息了，即進入廣播狀態。這時候當一個Server加入ZooKeeper服務中，它會在恢復模式下啟動，發現Leader，並和Leader進行狀態同步。待到同步結束，它也參與消息廣播。ZooKeeper服務一直維持在Broadcast狀態，直到Leader崩潰了或者Leader失去了大部分的Followers支持。
Broadcast模式極其類似於分佈式事務中的2pc（two-phrase commit 兩階段提交）：即Leader提起一個決議，由Followers進行投票，Leader對投票結果進行計算決定是否通過該決議，如果通過執行該決議（事務），否則什麼也不做。
四、監聽器原理
五、寫數據流程
六、常用命令
help 顯示所有操作命令
create 普通創建
-s 含有序列
-e 臨時（重啟或者超時消失）
set 設置節點的具體值
stat 查看節點狀態
delete 刪除節點
rmr 遞歸刪除節點
get path [watch] 獲得節點的值
ls path [watch] 使用 ls 命令來查看當前znode中所包含的內容
ls2 path [watch] 查看當前節點數據並能看到更新次數等數據
七、stat結構體
1）czxid-創建節點的事務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子節點數量
