扫码加入千人跳槽求职QQ群，每日都有全国招聘信息哦

Zookeeper 是一种分布式的，开源的，应用于分布式应用的协作服务。它提供了一些简单的操作，使得分布式应用可以基于这些接口实现诸如同步、配置维护和分集群或者命名的服务。Zookeeper 很容易编程接入，它使用了一个和文件树结构相似的数据模型。可以使用 Java 或者 C 来进行编程接入。

众所周知，分布式的系统协作服务很难有让人满意的产品。这些协作服务产品很容易陷入一些诸如竞争选择条件或者死锁的陷阱中。Zookeeper的目的就是将分布式服务不再需要由于协作冲突而另外实现协作服务。

本章内容：

1) Zookeeper 数据模型

2) Zookeeper 访问控制

3) Zookeeper 应用场景

1. Zookeeper 数据模型

ZooKeeper 拥有一个层次的命名空间，这个和标准的文件系统非常相似

从图中我们可以看出ZooKeeper的数据模型，在结构上和标准文件系统的非常相似，都是采用这种树形层次结构，ZooKeeper树中的每个节点被称为—Znode。和文件系统的目录树一样，ZooKeeper 树中的每个节点可以拥有子节点。但也有不同之处：

1) 引用方式:

Zonde 通过路径引用，如同 Unix 中的文件路径。路径必须是绝对的，因此他们必须由斜杠字符来开头。除此以外，他们必须是唯一的，也就是说每一个路径只有一个表示，因此这些路径不能改变。在 ZooKeeper 中，路径由 Unicode 字符串组成，并且有一些限制。字符串"/zookeeper"用以保存管理信息，比如关键配额信息。

2) Znode 结构

ZooKeeper命名空间中的Znode，兼具文件和目录两种特点。既像文件一样维护着数据、元信息、ACL、时间戳等数据结构，又像目录一样可以作为路径标识的一部分。图中的每个节点称为一个 Znode。每个 Znode 由 3 部分组成:

 stat：此为状态信息, 描述该 Znode 的版本, 权限等信息

 data：与该 Znode 关联的数据

 children：该 Znode 下的子节点

ZooKeeper虽然可以关联一些数据，但并没有被设计为常规的数据库或者大数据存储，相反的是，它用来管理调度数据，比如分布式应用中的配置文件信息、状态信息、汇集位置等等。这些数据的共同特性就是它们都是很小的数据，通常以 KB 为大小单位。ZooKeeper的服务器和客户端都被设计为严格检查并限制每个Znode的数据大小至多1M，但常规使用中应该远小于此值。

3) 数据访问

ZooKeeper中的每个节点存储的数据要被原子性的操作。也就是说读操作将获取与节点相关的所有数据，写操作也将替换掉节点的所有数据。另外，每一个节点都拥有自己的ACL(访问控制列表)，这个列表规定了用户的权限，即限定了特定用户对目标节点可以执行的操作。

4) 节点类型

Persistent Nodes：永久有效地节点,除非client 显式的删除,否则一直存在。

Ephemeral Nodes：临时节点,仅在创建该节点 client 保持连接期间有效,一旦连接丢

失,zookeeper 会自动删除该节点。

Sequence Nodes：顺序节点,client 申请创建该节点时, ZooKeeper 会自动在节点路径末尾添加递增序号,这种类型是实现分布式锁,分布式 queue 等特殊功能的关键。

5) 监控

客户端可以在节点上设置 watch，我们称之为监视器。当节点状态发生改变时(Znode的增、删、改)将会触发 watch 所对应的操作。当 watch 被触发时，ZooKeeper 将会向客户端发送且仅发送一条通知，因为 watch 只能被触发一次，这样可以减少网络流量。

ZooKeeper可以为所有的读操作设置watch，这些读操作包括：exists()、getChildren()及 getData()。watch事件是一次性的触发器，当watch的对象状态发生改变时，将会触发此对象上watch所对应的事件。watch事件将被异步地发送给客户端，并且ZooKeeper为watch 机制提供了有序的一致性保证。理论上，客户端接收 watch 事件的时间要快于其看到 watch 对象状态变化的时间。

2. Zookeeper 问 访问 控制

传统的文件系统中，ACL 分为两个维度，一个是属组，一个是权限，子目录/文件默认继承父目录的 ACL。而在 Zookeeper 中，node 的 ACL 是没有继承关系的，是独立控制的。Zookeeper 的 ACL，可以从三个维度来理解：一是 scheme; 二是 user; 三是permission，通常表示为 scheme:id:permissions, 下面从这三个方面分别来介绍：

1) scheme: scheme 对应于采用哪种方案来进行权限管理，zookeeper实现了一个pluggable 的 ACL 方案，可以通过扩展 scheme，来扩展 ACL 的机制。

2) User：与 scheme 是紧密相关的，具体的情况在上面介绍 scheme 的过程都已介绍，这里不再赘述。

3) permission: zookeeper 目前支持下面一些权限：

3. Zookeeper 用 应用 场景

1) 数据发布与订阅(配置中心)

发布与订阅模型，即所谓的配置中心，顾名思义就是发布者将数据发布到ZK节点上，供订阅者动态获取数据，实现配置信息的集中式管理和动态更新。例如全局的配置信息，服务式服务框架的服务地址列表等就非常适合使用。

2) 分布式锁服务

分布式锁，这个主要得益于ZooKeeper为我们保证了数据的强一致性。锁服务可以分为两类，一个是保持独占，另一个是控制时序。

3) 分布式队列

队列方面，简单地讲有两种，一种是常规的先进先出队列，另一种是要等到队列成员聚齐之后的才统一按序执行。对于第一种先进先出队列，和分布式锁服务中的控制时序场景基本原理一致，这里不再赘述。第二种队列其实是在FIFO队列的基础上作了一个增强。通常可以在 /queue 这个 znode 下预先建立一个/queue/num 节点，并且赋值为 n(或者直接给/queue 赋值n)，表示队列大小，之后每次有队列成员加入后，就判断下是否已经到达队列大小，决定是否可以开始执行了。这种用法的典型场景是，分布式环境中，一个大任务Task A，需要在很多子任务完成(或条件就绪)情况下才能进行。这个时候，凡是其中一个子 任 务 完 成 ( 就 绪 )， 那 么 就 去 /taskList 下 建 立 自 己 的 临 时 时 序 节 点(CreateMode.EPHEMERAL_SEQUENTIAL)，当 /taskList 发现自己下面的子节点满足指定个数，就可以进行下一步按序进行处理了。

想进入微信群的可扫码，备注入群

转发到朋友圈是最高的赞赏

因为不是天生丽质，所以必须天生励志！