ZooKeeper有一个分层的命名空间，类似分布式文件系统。它们唯一的区别就在于在命名空间中每个节点可以有数据关联作为它们的子节点。这就像有一个文件系统允许文件也作为文件目录。节点路径通常表示为规范的、斜杠分隔的绝对路径。它们没有相对路径。任何包含在路径当中的unicode字符都必须遵循以下约束：1）空字符不能作为路径名称；2）以下字符串不能作为使用，这是优越它们显示不够友好，或容易引起混淆（\u0001 – \u001F and \u007F – \u009F）3）以下字符串是不允许的。（ \ud800 – uF8FF, \uFFF0 – uFFFF）4）"."字符可以作为名称的一部分，但是"."和".."不能单独存在用于表示一个节点的路径，因为ZooKeeper没有使用相对路径。下述例子是无效的"/a/b/./c" or "/a/b/../c"5）"zookeeper"关键字保留
ZNodes
在ZooKeeper树形结构中的每个节点都可以称为znode。Znodes维护一个状态数据结构，包含数据变更版本号、ACL变更以及时间戳。版本号加上时间戳可以允许ZooKeeper去进行缓存换证和协调更新。每当一个znode的数据变更，版本号会往上加。比如每当客户端接收数据时，它也会接收到这个数据的版本。同时当客户端执行更新或删除操作时，它必须提供正在变化的znode节点的数据版本。如果znode提供的版本号不符合当前数据的实际版本号，更新将会失败。
注意：
在一个分布式应用工程中，单词node可以认为是单一主机、一个服务器、一个整体的其中某个成员，一个客户端处理器等等。在ZooKeeper文档中，znodes被认为是数据节点。Servers被认为是组成ZooKeeper服务的主机。quorum peers被认为是组成一个整体的服务端，clients被认为是正在使用ZooKeeper服务的一个主机或者是一个进程。
Znodes是程序员访问的主要实体。它们有很多特性值得我们了解的：
Watches（监听器）
客户端可以在znodes进行监听。znode的变化会触发这个监听器然后清除它。当一个监听器被触发的时候，ZooKeeper会给客户端发送一个通知。
Data Access（数据访问）
在命名空间当中存储在znode当中的数据是原子读或写的。读操作将会读取znode关联的所有数据字节，写操作将会替换所有数据。每个节点有Access Control List (ACL)数据访问列表用于限制谁可以做什么。
ZooKeeper不是设计用于作为数据库或者大对象存储的，相反的他是用来管理协调数据的。数据的来源形式可以是配置信息、状态信息、地区信息等等。不同形式的协调数据的通用属性是他们都相对比较小，控制在KB字节。ZooKeeper客户端和服务端都有合理性检查以保证znodes小于1M数据，但是数据可以远远小于这个平均值。在相对比较大的数据进行操作将会导致操作花费的时间较长，从而影响到其他操作的延迟，因为这额外的时间需要通过网络或者存储介质进行数据的迁移。如果大数据的存储是必须的，通常处理这种数据的方式是保持在大存储系统中，如NFS或者HDFS，然后在ZooKeeper中存储指向数据存储位置的指针。
Ephemeral Nodes（临时节点）
ZooKeeper有临时节点的概念。只要创建节点的会话还处于活跃状态，那这些节点还是存在的，当会话关闭时，这些节点也会被删除。因为这个行为所以临时节点不允许有子节点。
Sequence Nodes — Unique Naming（序列节点-独特命名）
当创建一个节点的时候你可以请求ZooKeeper在路径末尾增加一个单调递增的计数器。这个计数器对这个父节点是唯一的。计数器的格式是%010d （10进制用0填充），格式化以便用于简单排序。例如"<path>0000000001"。查看Queue Recipe 有一个例子用了这个特性。注意：这个用于存储下一个序列号的计数器是一个被父节点维护的有符号的int。这个计数器当递增超过2147483647 会溢出（结果应该是"<path>-2147483647"）。
以上就是ZooKeeper数据模型的详细内容，更多请关注其它相关文章！
别想一下造出大海，必须先由小河川开始。
