ZooKeeper 特點/設計目的
ZooKeeper 作為一個集群提供數據一致的協調服務，自然，最好的方式就是在整個集群中的 各服務節點進行數據的復制和同步。
數據復制的好處
1、容錯：一個節點出錯，不至於讓整個集群無法提供服務
2、擴展性：通過增加服務器節點能提高 ZooKeeper 系統的負載能力，把負載分布到多個節點上
3、高性能：客戶端可訪問本地 ZooKeeper 節點或者訪問就近的節點，依次提高用戶的訪問速度
設計目的
1、最終一致性：client不論連接到哪個Server，展示給它都是同一個視圖，這是zookeeper最重要的性能。
2、可靠性：具有簡單、健壯、良好的性能，如果消息被到一台服務器接受，那么它將被所有的服務器接受。
3、實時性：Zookeeper保證客戶端將在一個時間間隔范圍內獲得服務器的更新信息，或者服務器失效的信息。但由於網絡延時等原因，Zookeeper不能保證兩個客戶端能同時得到剛更新的數據，如果需要最新數據，應該在讀數據之前調用sync()接口。
4、等待無關（wait-free）：慢的或者失效的client不得干預快速的client的請求，使得每個client都能有效的等待。
5、原子性：更新只能成功或者失敗，沒有中間狀態。
6、順序性：包括全局有序和偏序兩種：全局有序是指如果在一台服務器上消息a在消息b前發布，則在所有Server上消息a都將在消息b前被發布；偏序是指如果一個消息b在消息a后被同一個發送者發布，a必將排在b前面。
ZooKeeper 典型應用場景
命名服務
命名服務是分布式系統中較為常見的一類場景，分布式系統中，被命名的實體通常可以是集 群中的機器、提供的服務地址或遠程對象等，通過命名服務，客戶端可以根據指定名字來獲 取資源的實體、服務地址和提供者的信息。Zookeeper 也可幫助應用系統通過資源引用的方 式來實現對資源的定位和使用，廣義上的命名服務的資源定位都不是真正意義上的實體資源， 在分布式環境中，上層應用僅僅需要一個全局唯一的名字。Zookeeper 可以實現一套分布式 全局唯一 ID 的分配機制。
配置管理
程序總是需要配置的，如果程序分散部署在多台機器上，要逐個改變配置就變得困難。現在 把這些配置全部放到 ZooKeeper 上去，保存在 ZooKeeper 的某個目錄節點中，然后所有相關應用程序對這個目錄節點進行監聽，一旦配置信息發生變化，每個應用程序就會收到 ZooKeeper 的通知，然后從 ZooKeeper 獲取新的配置信息應用到系統中就好
集群管理
所謂集群管理無在乎兩點：是否有機器退出和加入、選舉 master。
對於第一點，所有機器約定在父目錄 GroupMembers 下創建臨時目錄節點，然后監聽父目錄 節點的子節點變化消息。一旦有機器掛掉，該機器與 ZooKeeper 的連接斷開，其所創建的 臨時目錄節點被刪除，所有其他機器都收到通知：某個兄弟目錄被刪除，於是，所有人都知 道：有兄弟掛了。新機器加入也是類似，所有機器收到通知：新兄弟目錄加入，又多了個新 兄弟。
對於第二點，我們稍微改變一下，所有機器創建臨時順序編號目錄節點，每次選取編號最小 的機器作為 master 就好。當然，這只是其中的一種策略而已，選舉策略完全可以由管理員 自己制定。
分布式鎖
有了 ZooKeeper 的一致性文件系統，鎖的問題變得容易。 鎖服務可以分為兩三類
一個是寫鎖，對寫加鎖，保持獨占，或者叫做排它鎖，獨占鎖
一個是讀鎖，對讀加鎖，可共享訪問，釋放鎖之后才可進行事務操作，也叫共享鎖
一個是控制時序，叫時序鎖
對於第一類，我們將 ZooKeeper 上的一個 znode 看作是一把鎖，通過 createznode 的方式來 實現。所有客戶端都去創建 /distribute_lock 節點，最終成功創建的那個客戶端也即擁有了 這把鎖。用完刪除掉自己創建的 distribute_lock 節點就釋放出鎖
對於第二類， /distribute_lock 已經預先存在，所有客戶端在它下面創建臨時順序編號目錄 節點，和選 master 一樣，編號最小的獲得鎖，用完刪除，依次有序
隊列管理
兩種類型的隊列：
1、同步隊列：當一個隊列的成員都聚齊時，這個隊列才可用，否則一直等待所有成員到達。
2、先進先出隊列：隊列按照 FIFO 方式進行入隊和出隊操作。
第一類，在約定目錄下創建臨時目錄節點，監聽節點數目是否是我們要求的數目。
第二類，和分布式鎖服務中的控制時序場景基本原理一致，入列有編號，出列按編號。 同步隊列的流程圖：
