以前在做別的項目時用過zk，但沒有過多深入的學習，本着通俗易懂、簡單方便學習成本低的方式，建議大家耐心看完，如果文章中有不清楚的地方，可發私信進步探討！
學習zk共分為二部分，第一部分主要以理論為主。講解架構原理、數據結構等。 第二部分主要以操作API為主。包含集群的搭建、API的操作，zk負載均衡。第三部分主要以
實現：分布式鎖的實現
本篇讀完預計6分鍾
一．Zookeeper 簡介
1.簡介(重點)
zooKeeper是Hadoop的開源子項目（Google Chubby的開源實現），它是一個針對大型分布式系統的可靠協調系統。
提供的功能包括：統一命名服務、配置管理、分布式鎖、集群節點狀態協調(負載均衡/主從協調)
統一命名服務：在zk上注冊多個臨時服務A，當有某個服務A出現故障時，會自動從zk中刪除，停止對外提供服務，
配置管理：當有配置文件發生變化時，可以通過設置事件監聽的方式，通知client端進行配置的更新
分布式鎖：當多個應用服務同時訪問1個共享資源時，應用服務應向zk注冊自己臨時有序的節點信息，當有client要訪問共享資源時，先獲取所有的應用服務注冊信息，然后規定算法(例最小)，讓client端與自己的信息匹配時區取鎖進行訪問，訪問結束時釋放鎖，重新注冊，以便下次訪問。
集群的負載均衡：應用服務啟動時向zk注冊本機節點的配置信息，並在節點設置計數器，當有client連接時+1，斷開時-1，每次當有client連接時會獲取計數器最小的客戶端進行訪問
其實zk本身並不能提供以上的服務協調，它只能幫我們在節點上存儲一些簡單的數據，當這些數據發生變化的時候通過異步的方式通知我們，我們再根據這些數據的狀態進行相應的處理，其實現模式類似於觀察者模式。
zk本質的功能是：1.替客戶端保管數據 2.為客戶提供數據的監聽服務
二．zookeeper 的數據模型
其實zk中的節點上維護的數據模型，類似於我們windows 操作系統中盤符的路徑：C:/Program Files/java ,只不過這種路徑的節點可以存儲數據，還具有原子性等一些特點。
zk本身維護了一個基於內存的數據庫，用來存儲節點的數據信息，並且讀的速度要比寫的速度更快，這個數據結構是以樹狀的結構將數據進行存儲的。
1 數據模型
zookeeper 提供一種類似目錄樹結構的數據模型，每個節點（znode）具有唯一的路徑標識，而路徑是由斜線分隔開的路徑名序列組成，和標准的文件系統非常類似，例
2 .znode 節點(重點)
每一個節點稱為znode，通過路徑來訪問
每一個znode維護着：數據、stat數據結構（ACL、時間戳及版本號）
znode維護的數據主要是用於存儲協調的數據，如狀態、配置、位置等信息，每個節點存儲的數據量很小，KB級別
znode的數據更新后，版本號等控制信息也會更新（增加）
znode還具有原子性操作的特點：寫--全部替換，讀--全部(每個 znode 的數據將被原子性地讀寫，讀操作會讀取與 znode相關的所有數據，寫操作會一次性替換所有數據.)
znode有永久節點和臨時節點之分：臨時節點指創建它的session一結束，該節點即被zookeeper刪除；(非常重要)
另：zookeeper 並沒有被設計為常規的數據庫或者大數據存儲， 相反的是，它用來管理調度數據，比如分布式應用中的配置文件信息、狀態信息、匯集位置等等。這些數據的共同特性就是它們都是很小的數據，通常以 KB 為大小單位。 zooKeeper 的服務器和客戶端都被設計為嚴格檢查並限制每個 znode 的數據大小至多 1M。
3 .znode 節點的4種類型(重點)
PERSISTENT：永久節點
EPHEMERAL：臨時節點
PERSISTENT_SEQUENTIAL：永久節點、序列化
EPHEMERAL_SEQUENTIAL：臨時節點、序列化
二．Zookeeper 的架構和原理
1 .服務器中的角色定義
啟動 zookeeper 服務器集群環境后，多個 Zookeeper 服務器在工作前會選舉出一個 Leader。選舉出 leader 前，所有 server 不區分角色，都需要平等參與投票（observer 除外，不參與投票）；選主過程完成后，存在以下幾種角色：
leader : 領導者，可以接受 client 請求，也接收其他 server 轉發的寫請求，負責更新系統狀態。
follower : 可以接收 client 請求，如果是寫請求將轉發給 leader 來更新系統狀態。
observer ：同 follower，唯一區別就是不參與選主過程。
2.系統架構(了解)
zookeeper 分為服務器端（server）和客戶端（client），客戶端可以連接到整個 zooKeeper服務所提供的任意zk服務器上，訪問過程是當有客戶端(client）訪問服務端(leader服務器)時，leader服務器返回1個可訪問的地址給客戶端，然后客戶端通過這個地址訪問到zk服務器(follower)上。客戶端使用並維護一個 TCP 連接，通過這個連接發送請求、接受響應、獲取觀察的事件以及發送心跳。如果這個 TCP 連接中斷，客戶端將自動嘗試連接到另外的 zooKeeper 服務器。客戶端第一次連接到 zooKeeper 服務時，接受這個連接的 zooKeeper 服務器會為這個客戶端建立一個會話。當這個客戶端連接到另外的服務器時，這個會話會被新的服務器重新建立。
3.Session 機制原理(了解)
在client 連接 server 成功后， server 賦予該 client 一個 sessionid，client 需要不斷發送心跳維持 session 有效，在 session 有效期內，可以使用 Zookeeper 提供的 API 進行操作。如果因為某些原因導致 client 無法正常發送心跳，在超時時長后， server會判斷該 client 的 session 失效，此時 client 發送的任何操作都會被拒絕，並觸發ExpiredException (失效異常)，此時 KeeperState 處於 Expired 狀態。
但 client 有自動重連 server 的機制， 如果 client 的心跳無法正常連接 server，會在 session 超時前嘗試連接其他 server，連接成功后可以繼續操作。 如果 client 取消當前連接並連接其他 server，已存在的 watches 會丟失，取而代之的是client 會生成一個特殊 WatchEvent 告訴本地 watcher 連接已經丟失，該 WatchEvent 是：EventType.None， KeeperState.DisConnected。 本地 watcher 接收到該 WatchEvent 后會怎樣？
三．Watcher 監聽事件(重點)
zk對Node節點的增、刪、改、查都可觸發監聽
Watch事件是一次性觸發器，只有被Watch 監聽的數據發生變化時才被觸發，通過異步的方式通知該client端(觀察者)。
Watch是一次性觸發的並且在獲取Watch事件和設置新watch事件之間有延遲所以不能可靠的觀察到節點的每一次變化，但這個變化是毫秒級的，基本上不影響
客戶端監視一個節點，總是先獲取Watch事件，再發現節點的數據變化，Watch事件的順序對應於zk服務所見的數據更新的順序。
如果你還不是很清楚，看第二部分API操作
----------------------------------------------------------------------
創建監聽的三個地方：
判斷該節點是否存在時 ： exits(path,watcher);
監聽的事件是：該節點是否存在/刪除/數據是否發生改變
獲取某節點的子節點時 ： getChild(pathc,watcher);
監聽的事件是：該節點下是否有子節點創建/刪除
獲取該節點的數據時 ： getData(pathc,watcher);
監聽的事件是：該節點下的數據發生改變時