Question

ZooKeeper 包含一个树形的数据模型，我们叫做 znode。一个 znode 中包含了存储的数据和 ACL（Access Control List）。ZooKeeper 的设计适合存储少量的数据，并不适合存储大量数据，所以 znode 的存储限制最大不超过 1M。

数据的访问被定义成原子性的。什么是原子性呢？一个客户端访问一个 znode 时，不会只得到一部分数据；客户端访问数据要么获得全部数据，要么读取失败，什么也得不到。相似的，写操作时，要么写入全部数据，要么写入失败，什么也写不进去。ZooKeeper 能够保证写操作只有两个结果，成功和失败。绝对不会出现只写入了一部分数据的情况。与 HDFS 不同，ZooKeeper 不支持字符的 append（连接）操作。原因是 HDFS 是被设计成支持数据流访问（streaming data access）的大数据存储，而 ZooKeeper 则不是。

我们可以通过 path 来定位 znode，就像 Unix 系统定位文件一样，使用斜杠来表示路径。但是，znode 的路径只能使用绝对路径，而不能想 Unix 系统一样使用相对路径，即 Zookeeper 不能识别 ../ 和 ./ 这样的路径。

节点的名称是由 Unicode 字符组成的，除了 zookeeper 这个字符串，我们可以任意命名节点。为什么不能使用 zookeeper 命名节点呢？因为 ZooKeeper 已经默认使用 zookeeper 来命名了一个根节点，用来存储一些管理数据。

请注意，这里的 path 并不是 URIs，在 Java API 中是一个 String 类型的变量。

Ephemeral znodes

我们已经知道，znode 有两种类型：ephemeral 和 persistent。在创建 znode 时，我们指定 znode 的类型，并且在之后不会再被修改。当创建 znode 的客户端的 session 结束后，ephemeral 类型的 znode 将被删除。persistent 类型的 znode 在创建以后，就与客户端没什么联系了，除非主动去删除它，否则他会一直存在。Ephemeral znode 没有任何子节点。

虽然 Ephemeral znode 绑定了客户端 session，但是对任何其他客户端都是可见的，当然是在他们的 ACL 策略下允许访问的情况下。

当我们在创建分布式系统时，需要知道分布式资源是否可用。Ephemeral znode 就是为这种场景应运而生的。正如我们之前讲述的例子中，使用 Ephemeral znode 来实现一个成员关系管理，任何一个客户端进程任何时候都可以知道其他成员是否可用。

Znode 的序号

如果在创建 znode 时，我们使用排序标志的话，ZooKeeper 会在我们指定的 znode 名字后面增加一个数字。我们继续加入相同名字的 znode 时，这个数字会不断增加。这个序号的计数器是由这些排序 znode 的父节点来维护的。

如果我们请求创建一个 znode，指定命名为 /a/b- ，那么 ZooKeeper 会为我们创建一个名字为 /a/b-3 的 znode。我们再请求创建一个名字为 /a/b- 的 znode，ZooKeeper 会为我们创建一个名字 /a/b-5 的 znode。ZooKeeper 给我们指定的序号是不断增长的。Java API 中的 create() 的返回结果就是 znode 的实际名字。

那么序号用来干什么呢？当然是用来排序用的！后面《A Lock Service》中我们将讲述如何使用 znode 的序号来构建一个 share lock。

观察模式 Watches

观察模式可以使客户端在某一个 znode 发生变化时得到通知。观察模式有 ZooKeeper 服务的某些操作启动，并由其他的一些操作来触发。例如，一个客户端对一个 znode 进行了 exists 操作，来判断目标 znode 是否存在，同时在 znode 上开启了观察模式。如果 znode 不存在，这 exists 将返回 false 。如果稍后，另外一个客户端创建了这个 znode，观察模式将被触发，将 znode 的创建事件通知之前开启观察模式的客户端。我们将在以后详细介绍其他的操作和触发。

观察模式只能被触发一次。如果要一直获得 znode 的创建和删除的通知，那么就需要不断的在 znode 上开启观察模式。在上面的例子中，如果客户端还继续需要获得 znode 被删除的通知，那么在获得创建通知后，客户端还需要继续对这个 znode 进行 exists 操作，再开启一次观察模式。

在《A Configuration Service》中，有一个例子将讲述如何使用观察模式在集群中更新配置。