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的架构设计与角色分工。

评论不能及时回复可直接加公众号提问或交流，知无不答，谢谢 。