zookeeper-操做與應用場景-《每日五分鐘搞定大數據》

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部分組成:

1. stat狀態信息：描述該Znode的版本, 權限等信息
2. data：與該Znode關聯的數據(配置文件信息、狀態信息、聚集位置)，數據大小至多1M
3. children：該Znode下的子節點

ZooKeeper中的每一個節點存儲的數據要被原子性的操做。也就是說讀操做將獲取與節點相關的全部數據，寫操做也將替換掉節點的全部數據。另外，每個節點都擁有本身的ACL(訪問控制列表)，這個列表規定了用戶的權限，即限定了特定用戶對目標節點能夠執行的操做。

2.2.watch機制

ZooKeeper能夠爲全部的讀操做設置watch，包括：exists()、getChildren()及getData()。當節點狀態發生改變時(Znode的增、刪、改)將會觸發watch所對應的操做。當watch被觸發時，ZooKeeper將會向客戶端發送且僅發送一條通知，由於watch只能被觸發一次，這樣能夠減小網絡流量。

1. 數據watch(data watches)：getData和exists負責設置數據watch
2. 孩子watch(child watches)：getChildren負責設置孩子watch

2.3.節點類型

ZooKeeper中的節點有兩種，分別爲臨時節點和永久節點(還可再分爲有序無序)。節點的類型在建立時即被肯定，而且不能改變。

1. 臨時節點：該節點的生命週期依賴於建立它們的會話。一旦會話(Session)結束，臨時節點將被自動刪除，固然能夠也能夠手動刪除。雖然每一個臨時的Znode都會綁定到一個客戶端會話，但他們對全部的客戶端仍是可見的。另外，ZooKeeper的臨時節點不容許擁有子節點。（分佈式隊列）
2. 永久節點：該節點的生命週期不依賴於會話，而且只有在客戶端顯示執行刪除操做的時候，他們才能被刪除。

3.這些應用是如何經過這些特性實現的

3.1.HA:

兩種方式：

1. 建立兩個或多個有序臨時節點，永遠把最小值當作master
2. 建立臨時節點的爲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的架構設計與角色分工。

評論不能及時回覆可直接加公衆號提問或交流，知無不答，謝謝 。