Zookeeper作為一個分散式協調系統提供了一項基本服務：分散式鎖服務，分散式鎖是分散式協調技術實現的核心內容。像配置管理、任務分發、組服務、分散式訊息佇列、分散式通知/協調等，這些應用實際上都是基於這項基礎服務由使用者自己摸索出來的。
1.Zookeeper在大資料系統中的常見應用
zookeeper作為分散式協調系統在大資料領域非常常用，它是一個很好的中心化管理工具。下面舉幾個常見的應用場景。
1.1.HDFS/YARN
-
HA(分散式鎖的應用)：Master掛掉之後迅速切換到slave節點。
1.2.hbase
- HA ：同上。
- 配置管理 ：client需要讀寫hbase的資料首先都是連到ZK讀取root表，獲得meta表所在的region，最後找到資料所在位置。
-
任務釋出：regionserver掛了一臺，master需要重新分配region，會把任務放在zookeeper等regionserver來獲取
1.3.kafka
- 配置管理：broker會在zookeeper註冊並保持相關的後設資料（topic，partition資訊等）更新
-
任務分配：給topic分配partitions和replication
2.Zookeeper有哪些操作特性
2.1.資料結構
ZooKeeper名稱空間中的Znode，兼具檔案和目錄兩種特點。既像檔案一樣維護著資料、元資訊、ACL、時間戳等資料結構，又像目錄一樣可以作為路徑標識的一部分。 每個Znode由3部分組成:
- stat狀態資訊：描述該Znode的版本, 許可權等資訊
- data：與該Znode關聯的資料(配置檔案資訊、狀態資訊、彙集位置)，資料大小至多1M
- children：該Znode下的子節點
ZooKeeper中的每個節點儲存的資料要被原子性的操作。也就是說讀操作將獲取與節點相關的所有資料，寫操作也將替換掉節點的所有資料。另外，每一個節點都擁有自己的ACL(訪問控制列表)，這個列表規定了使用者的許可權，即限定了特定使用者對目標節點可以執行的操作。
2.2.watch機制
ZooKeeper可以為所有的讀操作設定watch，包括：exists()、getChildren()及getData()。當節點狀態發生改變時(Znode的增、刪、改)將會觸發watch所對應的操作。當watch被觸發時，ZooKeeper將會向客戶端傳送且僅傳送一條通知，因為watch只能被觸發一次，這樣可以減少網路流量。
- 資料watch(data watches)：getData和exists負責設定資料watch
- 孩子watch(child watches)：getChildren負責設定孩子watch
2.3.節點型別
ZooKeeper中的節點有兩種，分別為臨時節點和永久節點(還可再分為有序無序)。節點的型別在建立時即被確定，並且不能改變。
- 臨時節點：該節點的生命週期依賴於建立它們的會話。一旦會話(Session)結束，臨時節點將被自動刪除，當然可以也可以手動刪除。雖然每個臨時的Znode都會繫結到一個客戶端會話，但他們對所有的客戶端還是可見的。另外，ZooKeeper的臨時節點不允許擁有子節點。（分散式佇列）
- 永久節點：該節點的生命週期不依賴於會話，並且只有在客戶端顯示執行刪除操作的時候，他們才能被刪除。
3.這些應用是如何通過這些特性實現的
3.1.HA:
兩種方式：
- 建立兩個或多個有序臨時節點，永遠把最小值當做master
- 建立臨時節點的為master，多個slave會watch這個節點
3.2.配置管理：
儲存叢集後設資料提供給client使用，體現在比如需要對HBase和Kafka操作時，都會直接連到zookeeper，zookeeper記錄了資料儲存的位置，存活的節點等後設資料資訊。
3.3.任務釋出：
Master要監視/works和/tasks兩個永久節點，以便能感知到由哪些slave當前可用，當前有新任務需要分配。
分配過程：在/assign下建立當前可用的workA，找到需要分配的taskA，建立/assign/workA/taskA
zookeeper還有很多類似的應用大多都是基於上面的特性。總的來說，zk只是一個提供了一些特性的系統，使用者根據這些特性自己定義了它的用法。熟悉了zk的操作以及應用場景，下一篇說下zk的架構設計與角色分工。
評論不能及時回覆可直接加公眾號提問或交流，知無不答，謝謝 。
