1.Zookeepr是什麼
Zookeeper是一個典型的分佈式數據一致性的解決方案，分佈式應用程序可以基於它實現諸如數據發佈/訂閱，負載均衡，命名服務，分佈式協調/通知。集羣管理，Master選舉，分佈式鎖和分佈式隊列等功能。
2.zookeeper可以保證的分佈式一致性
a.順序一致性
從一個客戶端發起的事務請求，最終將會嚴格地按照其發起順序被應用到zookeeper中去
b.原子性
所有事務請求的處理結果在整個集羣中所有機器上的應用情況是一致的。
c.單一視圖
任意客戶端看到的服務器數據模型都是一致的
d.可靠性
一旦服務成功的應用了一個事務，並完成對客戶端響應，那麼該事務所引起的服務端狀態變更將會被一直保留下來，除非另一個事務又對其進行變更
e.實時性
Zookeeper僅僅保證在一定時間內，客戶端最終一定能夠從服務器上讀取到最新的數據狀態。
3.zookeeper的設計目標
目標一：簡單的數據模型
Zookeeper可以讓分佈式程序能通過一個共享的、樹型結構的名字空間來進行相互協調（和windows系統的文件結構相同，是有一系列的ZNode節點之間的層級關係構成）
目標二：可構建集羣
3到5臺機器就可以組成一個可用的zookeeper集羣
目標三：順序訪問
對於來自客戶端的每一個更新請求，zookeeper都會分配一個全局唯一的遞增編號，這個編號反應了所有事務操作的先後順序。
目標四：高性能
Zookeeper把所有的節點數據都存儲在內存中（提高了服務器吞吐、減少了延遲），並直接服務於客戶端所有非事務請求，因此尤其適用於以讀操作爲主的應用場景。
4.zookeeper的基本概念
集羣角色
在 zookeeper 集羣中，各個節點總共有三種角色，分別是：leader，follower，observer
而不是Master/slave（主備機模式）
會話（session）
Session是指客戶端的會話，Zookeeper對外的端口默認2181，可以通過sessionTimeout設置會話超時時間，由於服務器壓力、網絡原因或客戶端主動斷開等原因使客戶端鏈接斷開，只要在sessionTimeout規定時間內就能夠重新鏈接上集羣的任意一臺服務器，之前的會話仍然有效。
數據節點（ZNode）
ZNode保存在zookeeper內存中，數據模型是一個樹（ZNode Tree）由（/）進行分割路徑
版本
每個節點都會存儲數據，zookeeper會爲其維護一個Stat的數據結構，其中包括三個版本信息
cversion= 0 子節點的版本號
aclVersion= 0 表示acl的版本號，修改節點權限
dataVersion= 1 表示的是當前節點數據的版本號
Watcher
Watcher(事件監聽器)，非常重要的特性。Zookeeper允許用戶在指點節點上註冊一些Watcher，並在一些特定的事件觸發的時候，通知客戶端（可實現分佈式協調服務）
Zookeeper的Watcher VS JVM?
從某種角度來說，可以這樣對比（個人看法，可以討論），ZooKeeper對等於JVM，ZooKeeper包含狀態對象（ZNode）和分佈式進程的底層執行引擎Zab，而JVM內部包含堆（多線程共享的大量對象存放區域）和多線程執行正確性約束規範JMM（Java內存模型），JMM確保了多線程的執行順序是正確的。Zab協議使得ZooKeeper的內部修改狀態操作直接是有序串行的，而JVM內部則是亂序並行的，需要添加額外的機制才能保證時序（內存屏障、處理器原子指令），而狀態讀取時，JVM和ZooKeeper都存在直接讀取時讀到舊數據，但ZooKeeper有Watch機制使得響應式讀取更高效，而JVM只能使用底層的內存屏障刷新共享狀態，以便其他線程再次讀取時獲得正確的新數據。
ZooKeeper提供的接口使得所有的分佈式進程的執行都是異步非阻塞的（WaitFree算法），內部是基於Version的CAS操作，而JVM提供了阻塞的和非阻塞的多種接口，有Synchronized、Volatile、AtomicOperations。基於接口之上構建線程或分佈式進程之間更復雜的同步或協調功能時，Java併發庫直接提供了閉鎖、循環柵欄、信號量等同步工具以及基礎的抽象隊列同步器，而ZooKeeper則需要用戶基於接口自行構建各種分佈式協調功能（分佈式鎖、分佈式發佈訂閱、集羣成員關係管理）
對比:
ZooKeeper JVM
共享狀態對象: ZNode 堆中對象
底層執行模式: Zab順序執行 多處理器併發執行（內存屏障、原子機器指令）
API接口: Get、Watch_Get、Cas_Set、Exist Synchronized、volatile、final、Atomic
協調或同步功能: 分佈式發佈訂閱、鎖、讀寫鎖 併發庫同步工具、基於抽象隊列同步器構建的同步組件
Zookepper的Watcher架構?
客戶端先向ZooKeeper服務端成功註冊想要監聽的節點狀態，同時客戶端本地會存儲該監聽器相關的信息在WatchManager中，當ZooKeeper服務端監聽的數據狀態發生變化時，ZooKeeper就會主動通知發送相應事件信息給相關會話客戶端，客戶端就會在本地響應式的回調相關Watcher的Handler
Zookeeper的Watcher機制主要包括客戶端線程、客戶端WatcherManager、Zookeeper服務器三部分。客戶端在向Zookeeper服務器註冊的同時，會將Watcher對象存儲在客戶端的WatcherManager當中。當Zookeeper服務器觸發Watcher事件後，會向客戶端發送通知，客戶端線程從WatcherManager中取出對應的Watcher對象來執行回調邏輯。
Zookepper的Watcher的特性?
1.Watch是一次性的，每次都需要重新註冊，並且客戶端在會話異常結束時不會收到任何通知，而快速重連接時仍不影響接收通知。
2.Watch的回調執行都是順序執行的，並且客戶端在沒有收到關注數據的變化事件通知之前是不會看到最新的數據，另外需要注意不要在Watch回調邏輯中阻塞整個客戶端的Watch回調
3.Watch是輕量級的，WatchEvent是最小的通信單元，結構上只包含通知狀態、事件類型和節點路徑。ZooKeeper服務端只會通知客戶端發生了什麼，並不會告訴具體內容。
ACL
access control list
權限控制
CREATE:創建子節點的權限
READ：獲取子節點數據和子節點列表的權限
WRITE：更新節點數據的權限
DELETE：刪除節點數據的權限
ADMIN：設置節點ACL的權限