一、什么是zookeeper
zooKeeper是一個分布式的，開放源碼的分布式應用程序協調服務，是Google的Chubby一個開源的實現，是Hadoop和Hbase的重要組件。它是一個為分布式應用提供一致性服務的軟件，提供的功能包括：配置維護、域名服務、分布式同步、組服務等。Zookeeper致力於為那些高吞吐的大型分布式系統提供一個高性能、高可用、且具有嚴格順序訪問控制能力的分布式協調服務。
簡單來說zookeeper=文件系統+監聽通知機制。
二、特性
1.順序一致性：從一個客戶端發起的事務請求，最終都會嚴格按照其發起順序被應用到Zookeeper中；對於來自客戶端的每個更新請求，Zookeeper都會分配一個全局唯一的遞增ID(zxid)，這個ID反映了所有事務請求的先后順序。
2.原子性：所有事務請求的處理結果在整個集群中所有機器上都是一致的
3.最終一致性：所有客戶端看到的服務端數據模型都是一致的；
4.可靠性：一旦服務端成功應用了一個事務，則其引起的改變會一直保留，直到被另外一個事務所更改,如果消息被到一台服務器接受，那么它將被所有的服務器接受。
5.實時性：一旦一個事務被成功應用后，Zookeeper可以保證客戶端立即可以讀取到這個事務變更后的最新狀態的數據。
6.等待無關（wait-free）：慢的或者失效的client不得干預快速的client的請求，使得每個client都能有效的等待。
"由於Zookeeper的所有更新和刪除都是基於事務的，所以其在讀多寫少的應用場景中有着很高的性能表現。" "ZooKeeper將數據存全量儲在內存中以保持高性能，並通過服務集群來實現高可用"
三、常見的應用場景
1. 數據的發布/訂閱 數據的發布/訂閱系統，通常也用作配置中心。在分布式系統中，你可能有成千上萬個服務節點，如果想要對所有服務的某項配置進行更改，由於數據節點過多，你不可逐台進行修改，而應該在設計時采用統一的配置中心。之后發布者只需要將新的配置發送到配置中心，所有服務節點即可自動下載並進行更新，從而實現配置的集中管理和動態更新。 Zookeeper通過Watcher機制可以實現數據的發布和訂閱。分布式系統的所有的服務節點可以對某個ZNode注冊監聽，之后只需要將新的配置寫入該ZNode，所有服務節點都會收到該事件。
2. 命名服務 在分布式系統中，通常需要一個全局唯一的名字，如生成全局唯一的訂單號等，Zookeeper可以通過順序節點的特性來生成全局唯一ID，從而可以對分布式系統提供命名服務。
3. Master選舉 分布式系統一個重要的模式就是主從模式(Master/Salves)，Zookeeper可以用於該模式下的Matser選舉。可以讓所有服務節點去競爭性地創建同一個ZNode，由於Zookeeper不能有路徑相同的ZNode，必然只有一個服務節點能夠創建成功，這樣該服務節點就可以成為Master節點。
4. 分布式鎖 可以通過Zookeeper的臨時節點和Watcher機制來實現分布式鎖，這里以排它鎖為例進行說明： 分布式系統的所有服務節點可以競爭性地去創建同一個臨時ZNode，由於Zookeeper不能有路徑相同的ZNode，必然只有一個服務節點能夠創建成功，此時可以認為該節點獲得了鎖。其他沒有獲得鎖的服務節點通過在該ZNode上注冊監聽，從而當鎖釋放時再去競爭獲得鎖。鎖的釋放情況有以下兩種： 當正常執行完業務邏輯后，客戶端主動將臨時ZNode刪除，此時鎖被釋放； 當獲得鎖的客戶端發生宕機時，臨時ZNode會被自動刪除，此時認為鎖已經釋放。 當鎖被釋放后，其他服務節點則再次去競爭性地進行創建，但每次都只有一個服務節點能夠獲取到鎖，這就是排他鎖。
5. 集群管理 Zookeeper還能解決大多數分布式系統中的問題： 如可以通過創建臨時節點來建立心跳檢測機制。如果分布式系統的某個服務節點宕機了，則其持有的會話會超時，此時該臨時節點會被刪除，相應的監聽事件就會被觸發。 分布式系統的每個服務節點還可以將自己的節點狀態寫入臨時節點，從而完成狀態報告或節點工作進度匯報。 通過數據的訂閱和發布功能，Zookeeper還能對分布式系統進行模塊的解耦和任務的調度。 通過監聽機制，還能對分布式系統的服務節點進行動態上下線，從而實現服務的動態擴容。
6.事務操作 在ZooKeeper中，能改變ZooKeeper服務器狀態的操作稱為事務操作。一般包括數據節點創建與刪除、數據內容更新和客戶端會話創建與失效等操作。 對應每一個事務請求，ZooKeeper都會為其分配一個全局唯一的事務ID，用 ZXID 表示，通常是一個64位的數字。每一個 ZXID對應一次更新操作， 從這些 ZXID 中可以間接地識別出 ZooKeeper 處理這些事務操作請求的全局順序。
四、優缺點
優點：
01.分布式協調過程簡單
02.同步: zk高度同步，這意味着服務器進程之間既存在互斥又存在合作，同步有助於Apache HBase進行配置管理。
3.有序消息: zk跟蹤一個數字，表示每個更新的順序，保證消息有序
04.序列化: 根據具體規則，zk對數據進行編碼。 另外，它還可確保我們的應用程序始終如一地運行。 但是，在MapReduce中，我們使用此方法（序列化）來協調隊列以執行正在運行的線程
05.速度: 在讀請求多的情況下，能以很快的速度運行
06.可擴展性: 此外，可以通過部署更多機器來加強zk的性能
07.有序性有何優勢？: 眾所周知，zk中的消息是有序的。 所以，為了實現更高級別的抽象，需要有序性。 這就是有序性對我們有利的方式
08.快: 在讀多的情況下，zk會非常快
09.可靠性: zk非常可靠，因為一旦zk更新了，更新后的數據會一直保持，直到被覆蓋更新
10.原子性: zk只有兩種情況，要么全部成功，要么全部失敗，沒有中間狀態的情況
11.實時性: zk保證在一定時間段內，客戶端最終一定能從服務器上讀到最新的數據狀態
局限性：
01.增加新的zk服務器時可能導致數據丟失
在現有服務器中，當新zk服務器數量超過zk服務中已存在的數量時數據會丟失。 同時，向zk服務發出Start命令，新服務器可能形成仲裁
02.不能遷移
在沒有用戶干預的情況下，zk服務器無法從版本3.4遷移到3.3，然后再遷移到3.4。
03.節點數（其實集群中只要存活數過半即對外可用，但是會有腦裂情況發生）
要求3或5個這樣奇數個zk節點（要求奇數是為了保證選舉的正常進行因為leader選舉要求 可用節點數量 > 總節點數/2，防止腦裂造成集群不可用。同時在容錯能力相同的情況下，奇數個節點更節省資源）
04.機架感知復制
目前，它不支持機架放置和感知
05.縮容
不支持減少pod的數量，以防止意外數據丟失
06.磁盤變更
不支持在初始部署后更改volume要求，以防止重新分配意外丟失數據
07.虛擬網絡
當服務部署在虛擬網絡上時，如果沒有完全重新安裝，服務可能無法切換到主機網絡。 另外，對於嘗試從主機切換到虛擬網絡，它們是相同的情況
08.Kerberos
在虛擬網絡上，它目前不支持啟用Kerberos
09.支持有限
對跨群集方案的支持非常有限。 但是，沒有CP系統會一直支持跨集群。 雖然我們可以說consul似乎在這方面做得更好
10.復雜
它非常重，所以它需要我們維持一個相當大的堆棧