引用百度百科的話
ZooKeeper是一個分布式的，開放源碼的分布式應用程序協調服務，是Google的Chubby一個開源的實現，是Hadoop和Hbase的重要組件。它是一個為分布式應用提供一致性服務的軟件，提供的功能包括：配置維護、域名服務、分布式同步、組服務等。
乍一看，又是啃概念的東西，用通俗的方式來認識Zookeeper。
先看看我們的12306，前兩年，我們會發現，平時使用時基本上沒什么問題，但是一到春運，12306就會很卡，網站甚至崩潰，因為流量太大，一台服務器扛不住這么大的壓力，畢竟一台服務器的資源是有限的。怎么解決這個問題呢，后人想了很多辦法，分布式是其中最有效的一個，既然一台服務器不夠，那就兩台，三台，甚至更多，這樣多個服務器就形成了一個集群，雖然解決了網站的流量壓力，但是是卻增加了維護的難度，比如這個集群有100台服務器，如果我們要修改其中一個配置，難道我們就要去每台服務器上去改么？當然要另辟新徑。Zookeeper是一個分布式的協調服務，它可以很好的解決這樣的問題。
Zookeeper集群
既然是分布式，必然我們需要多台服務器（當然也可以一台服務器開不同的端口，或者使用虛擬技術，或者使用docker之類的容器），最好是同一網段下，方便服務器之間要可以相互訪問。然后在每個服務器上安裝Zookeeper，並進行相關配置，這樣，這些就形成了一個Zookeeper集群，集群節點之間可以相互連接訪問。Zookeeper集群可以進行分布式數據同步，你通過集群的某個節點寫入數據，Zookeeper會自動將數據同步到其他節點。
Leader和Follower
假如我們有一個Zookeeper集群，集群中有三台服務器，如果這三台是一樣的擁有讀寫權限，那么會導致讀寫並發的問題（因為Zookeeper節點數據會同步，假如A、B兩節點同時寫入，那么C節點是同步取A的數據還是B的數據），因此Zookeeper規定，集群中只能有一個節點擁有寫權限，這個節點就是Leader節點，其他的全部都是Follower節點，Follower節點只擁有讀權限，而Leader節點擁有讀寫權限，因此如果應用通過Follower節點寫入數據，Follower節點會先將數據轉發到Leader節點，再由Leader節點寫入。如果集群中沒有Leader節點或者Leader節點故障了，那么集群內部會自動通過選舉確定新Leader節點（選舉算法主要有三個：leaderElection、AuthFastLeaderElection、FastLeaderElection，其中FastLeaderElection 是zookeeper 默認的一種算法）。
Zookeeper節點狀態一般認為有4個：
LOOKING：表示正在進行選舉的節點，處於該狀態需要進入選舉流程 LEADING：領導者狀態，處於該狀態的節點說明是角色已經是Leader FOLLOWING：跟隨者狀態，表示Leader已經選舉出來，當前節點角色是follower OBSERVER：觀察者狀態，表明當前節點角色是observer，observer表示不會進入選舉，僅僅只是接受選舉結果，也就是說不會成為Leader節點，但是是follower節點一樣提供服務。
Zookeeper集群中可以是一個節點或者兩個節點，但是一般認為，Zookeeper集群中至少需要3個節點，這是因為Zookeeper規定，當集群中達到一半的節點故障時，就表示集群出現故障，將不再對外服務，當正常服務節點超過一半時又會自動恢復服務狀態。 1、一台服務器體現不出Zookeeper的優勢，如果故障了，就表示集群故障了 2、二台服務器時，如果一台發生故障，則故障節點數達到了集群節點數據的一半，也就表示集群故障了 3、三台服務器時，當兩個節點故障時才表示集群故障 4、四台服務器時，當兩個節點故障時才表示集群故障 於是乎，一個節點和兩個節點的集群是不允許有故障節點的，而三個和四個節點的集群最多都是只能運行一個節點故障。 一般認為，Zookeeper集群中的節點是奇數，因為2n-1個節點的集群和2n個節點的集群運行的故障節點數都是n，這樣2n個節點的集群就可以節省一個節點的開銷了
Znode
Zookeeper維護一個樹形結構的數據集合，這個與我們的文件系統路徑相似，這個樹形結構中的每個節點稱為znode節點，從根節點(/)開始，默認情況下，znode節點可以擁有子節點，而且每個znode節點可以保存數據，因此我們開發者可以認為，對Zookeeper的操作其實就是對znode的讀寫操作。
znode節點可以分為三種：
PERSISTENT：持久節點，即使在創建該特定znode的客戶端斷開連接后，持久節點仍然存在。默認情況下，除非另有說明，否則所有znode都是持久的。 EPHEMERAL：臨時節點，客戶端是連接狀態時，臨時節點就是有效的。當客戶端與ZooKeeper集合斷開連接時，臨時節點會自動刪除。臨時節點不允許有子節點。臨時節點在leader選舉中起着重要作用。 SEQUENTIAL：順序節點，可以是持久的或臨時的。當一個新的znode被創建為一個順序節點時，ZooKeeper通過將10位的序列號附加到原始名稱來設置znode的路徑，順序節點在鎖定和同步中起重要作用。
或者說znode節點有四種：
PERSISTENT：持久節點 PERSISTENT_SEQUENTIAL：持久順序節點
EPHEMERAL：臨時節點
EPHEMERAL_SEQUENTIAL：臨時順序節點
每個znode都維護着一個 stat 結構。一個stat僅提供一個znode的元數據。它由版本號，操作控制列表(ACL)，時間戳和數據長度組成，也就是記錄znode節點的狀態等等信息。
版本號：每個znode都有版本號，這意味着每當與znode相關聯的數據發生變化時，其對應的版本號也會增加。當多個zookeeper客戶端嘗試在同一znode上執行操作時，版本號的使用就很重要。 操作控制列表(ACL)：ACL基本上是訪問znode的認證機制。它管理所有znode讀取和寫入操作。 時間戳：時間戳表示創建和修改znode所經過的時間。它通常以毫秒為單位。 數據長度：存儲在znode中的數據總量是數據長度。你最多可以存儲1MB的數據。
Watcher
Zookeeper允許客戶當往znode中注冊watcher，當對znode進行修改刪除，或者對znode的子節點進行修改刪除時，會通過注冊的watcher通知客戶端。
watcher只會觸發一次，如果需要再次觸發，則需要再次注冊watcher。
另外，當客戶端連接斷開時，watcher將自動被刪除。
總結：
用圖形象的表示：
結構：
操作：
