Zookeeper 分布式服務框架是 Apache Hadoop 的一個子項目，主要是用來解決分布式應用中經常遇到的一些數據管理問題。
如：集群管理、統(tǒng)一命名服務、分布式配置管理、分布式消息隊列、分布 式鎖、分布式通知協調等。
越來越多的分布式計算開始強依賴ZK，比如Storm、Hbase
Zookeeper對分布式開發(fā)帶來很多便利，用ZK的獨有特性巧妙地解決了很多難題； 很多分布式技術用到Zookeeper或多或少特性，尤其是新生代分布式技術幾乎都會依賴Zookeeper特性，如Hbase、火爆的Storm。
zookeeper名字空間由節(jié)點znode構成，其組織方式類似文件系統(tǒng)，其中各個節(jié)點相當于目錄和文件，通過路徑作為唯一標識。與文件系統(tǒng)不同的是，每個節(jié)點具有與之對應的數據內容，同時也可以具有子節(jié)點。
zookeeper用于存儲協調數據，如狀態(tài)、配置、位置等信息，每個節(jié)點存儲的數據量很小，KB級別。
節(jié)點維護一個狀態(tài)stat結構（包括數據變化的版本號、ACL變化、時間戳），以允許緩存驗證與協調更新。每當節(jié)點數據內容改變，多一個版本號，類似HBase?？蛻舳双@取數據的同時也會獲取數據版本號。節(jié)點的數據內容以原子方式讀寫。
節(jié)點具有一個訪問控制列表（AccessControl List - ACL）來約束訪問操作，即具有權限控制。
Watches：Zookeeper對Node的增、刪、改、查都可觸發(fā)監(jiān)聽
watch事件是一次性觸發(fā)器，當watch監(jiān)視的數據發(fā)生變化時，通知設置了該watch的client，即watcher
watch事件異步發(fā)送至觀察者
watch是一次性觸發(fā)的并且在獲取watch事件和設置新watch事件之間有延遲，所以不能可靠的觀察到節(jié)點的每一次變化
客戶端監(jiān)視一個節(jié)點，總是先獲取watch事件，再發(fā)現節(jié)點的數據變化
watch事件的順序對應于zookeeper服務所見的數據更新的順序
流行的應用場景
1、分布式應用配置管理
發(fā)布與訂閱即所謂的配置管理，顧名思義就是將數據發(fā)布到zk節(jié)點上，供訂閱者動態(tài)獲取數據，實現配置信息的集中式管理和動態(tài)更新。例如全局的配置信息，地址列表等就非常適合使用。
2、Name Service
這個主要是作為分布式命名服務，通過調用zk的create node api，能夠很容易創(chuàng)建一個全局唯一的path，這個path就可以作為一個名稱。序列化節(jié)點
3、分布式通知/協調
ZooKeeper中特有watcher注冊與異步通知機制，能夠很好的實現分布式環(huán)境下不同系統(tǒng)之間的通知與協調，實現對數據變更的實時處理。
使用方法：通常是不同系統(tǒng)都對ZK上同一個znode進行watch，監(jiān)聽znode的變化（包括znode本身內容及子節(jié)點的），其中一個系統(tǒng)update了 znode，那么另一個系統(tǒng)能夠收到通知，并作出相應處理。
3、分布式鎖
分布式鎖，這個主要得益于ZooKeeper為我們保證了數據的強一致性，zk集群中任意節(jié)點（一個zk server）上的相同znode的數據是一定是相同的。
鎖服務可以分為兩類，一個是保持獨占，另一個是控制時序。
4、集群管理
Hbase Master選舉則是zookeeper經典的使用場景；
Storm集群管理
5、分布式隊列
隊列方面，一種是常規(guī)的先進先出隊列，另一種是要等到隊列成員聚齊之后的才統(tǒng)一按序執(zhí)行。對于第二種先進先出隊列，增加分布式鎖服務以控制時序場景
