ZK是hadoop生態圈的一個很重要的項目之一，在集羣環境中，ZK的重要性越來越大，現在的集羣環境基本很難脫離ZK實現分佈式協調服務，任何集羣環境都一個類中心控制器來協調服務，如果是自己去設計編寫一個這樣子的應用程序，不僅給開發帶來很多難度,也不好去維護，大大降低效率，也消耗很多成本。所以使用ZK帶來的好處就是你不用花太多時間去關注技術上面的實現，而更多去注重業務上面的開發就可以，但是瞭解ZK會大大的提高我們的開發效率！
（1）ZK數據模型之初探
a. 層次化的目錄結構，類似於一棵倒起來的樹，命名符合常規文件規範。
b. 在zookeeper中每一個節點都叫做Znode,並且其有一個唯一的路徑標識。
c .Znode可以包含數據和子節點，但ephemeral類型的節點不能包含子節點，因爲ephemeral標識的節點是臨時的節點。
d. Zonde數據可以有多個版本，比如某一個路徑下面存在多個版本，查看這個路徑下面的數據要帶上版本號。
e. 客戶端應用可以在節點上設置監視器。
f.節點上的數據不支持部分讀寫，需要一次性完整讀寫，保證數據的原子性！
![]()
（2）ZK節點—Znode
a. znode可以被監控，包括目錄下面的數據的修改，子目錄的變化等，一旦變化可以通知設置監控的客戶端， 這個功能對於應用最重要的特性，通過這個特性可以實現的功能包括配置的集中管理、集羣管理、分佈式鎖等等。
b. znode有兩種節點，一種是持久的（Persistent）,另一種是臨時的（ephemeral）。
c. znode在創建選擇節點類型時確定並且之後不能再修改。
d. 短暫的znode在跟客戶端回話結束時，zookeeper會將改短暫的znode刪除，短暫的znode不能有子節點。
c.Znode有四種形式的目錄節點，PERSISTENT、PERSISTENT_SEQUENTIAL、EPHEMERAL、EPHEMERAL_SEQUENTIAL
d.Znode 可以是臨時節點，一旦創建這個 znode 的客戶端與服務器失去聯繫，這個znode 也將自動刪除，Zookeeper的客戶端和服務器通信採用長連接方式，每個客戶端和服務器通過心跳來保持連接，這個連接狀態稱爲 session，如果 znode 是臨時節點，這個 session 失效，znode 也就刪除了；持久化目錄節點，這個目錄節點存儲的數據不會丟失；順序自動編號的目錄節點，這種目錄節點會根據當前已近存在的節點數自動加1，然後返回給客戶端已經成功創建的目錄節點名；臨時目錄節點，一旦創建這個節點的客戶端與服務器端口也就是session
超時，這種節點會被自動刪除；臨時自動編號節點。
（3）ZK角色分析
a. 領導者（leader）,負責進行投票的發起和投票，更新系統狀態。
b. 學習者（learner），包括跟隨者（flower）跟觀察者（observer），flower接收客戶端的請求並向客戶端返回結果，在選舉過程參與投票。
c. observer可以接收客戶端的鏈接，將寫請求傳給leader，observer不參與投票過程，只同步leader狀態，observer的目的是爲了擴展系統，提高讀取速度。
d. 客戶端（client），發起請求。
![]()
（4）ZK的順序號
a. 創建znode時設置順序標識，znode名稱後會附加一個值。
b.順序號是一個單調遞增的計數器，由父節點維護。
c. 在分佈式系統中，順序號可以被用於爲所有的事件進行全局排序，這樣客戶端可以通過順序號推斷事件的順序。
（5）ZK的讀寫機制
a. Zookeeper是一個由多個server組成的集羣
b. 一個leader，多個follower
c. 每個server保存一份數據副本
d. 全局數據一致
e. 分佈式讀寫
f. 更新請求轉發，由leader實施
（7）ZK保證
a. 更新請求順序進行，來自同一個client的更新請求按其發送順序依次執行
b. 數據更新原子性，一次數據更新要麼成功，要麼失敗
c. 全局唯一數據視圖，client無論連接到哪個server，數據視圖都是一致的
d.實時性，在一定事件範圍內，client能讀到最新數據
（8）ZK的API接口
下面這些是我們常去操作ZK時要去實現的接口，這裏我也把他記下來了。
String create(String path, byte[] data, List<ACL> acl, CreateMode createMode)
Stat exists(String path, boolean watch)
void delete(String path, int version)
List<String> getChildren(String path, boolean watch)
List<String> getChildren(String path, boolean watch)
Stat setData(String path, byte[] data, int version)
byte[] getData(String path, boolean watch, Stat stat)
void addAuthInfo(String scheme, byte[] auth)
Stat setACL(String path, List<ACL> acl, int version)
List<ACL> getACL(String path, Stat stat)
（9）觀察（watcher）
a. Watcher 在 ZooKeeper 是一個核心功能，Watcher 可以監控目錄節點的數據變化以及子目錄的變化，一旦這些狀態發生變化，服務器就會通知所有設置在這個目錄節點
上的Watcher，從而每個客戶端都很快知道它所關注的目錄節點的狀態發生變化，而做出相應的反應
b. 可以設置觀察的操作：exists,getChildren,getData
c. 可以觸發觀察的操作：create,delete,setData
（10）ZK的 工作原理
Zookeeper的核心是原子廣播，這個機制保證了各個server之間的同步。實現這個機制的協議叫做Zab協議。Zab協議有兩種模式，它們分別是恢復模式和廣播模式。當服務啓動或者在領導者崩潰後，Zab就進入了恢復模式，當領導者被選舉出來，且大多數server的完成了和leader的狀態同步以後，恢復模式就結束了。狀態同步保證了leader和server具有相同的系統狀態。
一旦leader已經和多數的follower進行了狀態同步後，他就可以開始廣播消息了，即進入廣播狀態。這時候當一個server加入zookeeper服務中，它會在恢復模式下啓動，發現leader，並和leader進行狀態同步。待到同步結束，它也參與消息廣播。Zookeeper服務一直維持在Broadcast狀態，直到leader崩潰了或者leader失去了大部分的followers支持。（Broadcast模式極其類似於分佈式事務中的2pc（two-phrasecommit兩階段提交）：即leader提起一個決議，由followers進行投票，leader對投票結果進行計算決定是否通過該決議，如果通過執行該決議（事務），否則什麼也不做。）
廣播模式需要保證proposal被按順序處理，因此zk採用了遞增的事務id號(zxid)來保證。所有的提議(proposal)都在被提出的時候加上了zxid。實現中zxid是一個64爲的數字，
它高32位是epoch用來標識leader關係是否改變，每次一個leader被選出來，它都會有一個新的epoch。低32位是個遞增計數。
當leader崩潰或者leader失去大多數的follower，這時候zk進入恢復模式，恢復模式需要重新選舉出一個新的leader，讓所有的server都恢復到一個正確的狀態。
（11）Leader選舉
①選舉過程：
a. 每個Server啓動以後都詢問其它的Server它要投票給誰。
b. 對於其他server的詢問，server每次根據自己的狀態都回復自己推薦的leader的id和上一次處理事務的zxid（系統啓動時每個server都會推薦自己）
c. 收到所有Server回覆以後，就計算出zxid最大的哪個Server，並將這個Server相關信息設置成下一次要投票的Server。
d. 計算這過程中獲得票數最多的的sever爲獲勝者，如果獲勝者的票數超過半數，則改server被選爲leader。否則，繼續這個過程，直到leader被選舉出來。
注意：先看一下選舉的過程，zk的實現中用了基於paxos算法（主要是fastpaxos）的實現。具體如下；此外恢復模式下，如果是重新剛從崩潰狀態恢復的或者剛啓動
的server還會從磁盤快照中恢復數據和會話信息。（zk會記錄事務日誌並定期進行快照，方便在恢復時進行狀態恢復）。
e. leader就會開始等待server連接
f. Follower連接leader，將最大的zxid發送給leader
g. Leader根據follower的zxid確定同步點
h. 完成同步後通知follower 已經成爲uptodate狀態
i. Follower收到uptodate消息後，又可以重新接受client的請求進行服務了
注意：選完leader以後，zk就進入狀態同步過程。
②選舉狀態圖：
a. 工作狀態圖
-Observing: 觀察狀態，這時候observer會觀察leader是否有改變，然後同步leader的狀態；Following: 跟隨狀態，接收leader的proposal ，進行投票。
並和leader進行狀態同步。
b. 選擇狀態圖
-Looking: 尋找狀態，這個狀態不知道誰是leader，會發起leader選舉；Leading: 領導狀態，對Follower的投票進行決議，將狀態和follower進行同步。
