zookeeper的操作與應用場景是什么

本篇文章為大家展示了zookeeper的操作與應用場景是什么，內容簡明扼要并且容易理解，絕對能使你眼前一亮，通過這篇文章的詳細介紹希望你能有所收獲。

Zookeeper作為一個分布式協調系統提供了一項基本服務：分布式鎖服務，分布式鎖是分布式協調技術實現的核心內容。像配置管理、任務分發、組服務、分布式消息隊列、分布式通知/協調等，這些應用實際上都是基于這項基礎服務由用戶自己摸索出來的。

1.Zookeeper在大數據系統中的常見應用

zookeeper作為分布式協調系統在大數據領域非常常用，它是一個很好的中心化管理工具。下面舉幾個常見的應用場景。

1.1.HDFS/YARN

• HA機制(分布式鎖的應用)：Master掛掉之后迅速切換到slave節點。

1.2.hbase

• HA機制 ：類似HDFS/YARN。

• 配置管理 ：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只是一個提供了一些特性的系統，用戶根據這些特性自己定義了它的用法。

上述內容就是zookeeper的操作與應用場景是什么，你們學到知識或技能了嗎？如果還想學到更多技能或者豐富自己的知識儲備，歡迎關注億速云行業資訊頻道。