这些Server组成了Zookeeper service，他们必须相互知道。只有要大于半数的server存活，那么Zookeeper service就能提供服务。
Data model and the hierarchical namespace（数据模型和分层的namespace）
这些Server组成了Zookeeper service，他们必须相互知道。只有要大于半数的server存活，那么Zookeeper service就能提供服务。
Data model and the hierarchical namespace（数据模型和分层的namespace）
Zookeeper提供的namespace和标准的file system很相识，每一个path元素都是通过一个/分隔，在zookeeper中的namespace都是一个唯一。
与文件系统不同的是，Zookeeper的namespace能够存储数据，并且可以有子节点；和文件系统相同的是可以做为一个目录。
Zookeeper被设计用来存储系统数据，eg: 状态信息，配置信息，定位信息…，所以这些数据通常都非常的小。
ZooKeeper目录树中每一个节点对应一个Znode。每个Znode维护着一个属性结构，它包含着版本号(dataVersion)，时间戳(ctime,mtime)等状态信息。ZooKeeper正是使用节点的这些特性来实现它的某些特定功能。每当Znode的数据改变时，他相应的版本号将会增加。每当客户端检索数据时，它将同时检索数据的版本号。并且如果一个客户端执行了某个节点的更新或删除操作，他也必须提供要被操作的数据版本号。如果所提供的数据版本号与实际不匹配，那么这个操作将会失败。
Znode是客户端访问ZooKeeper的主要实体，它包含以下几个特征：
（1）Watches
客户端可以在节点上设置watch(我们称之为监视器)。当节点状态发生改变时(数据的增、删、改)将会触发watch所对应的操作。当watch被触发时，ZooKeeper将会向客户端发送且仅发送一条通知，因为watch只能被触发一次。
（2）数据访问
ZooKeeper中的每个节点存储的数据要被原子性的操作。也就是说读操作将获取与节点相关的所有数据，写操作也将替换掉节点的所有数据。另外，每一个节点都拥有自己的ACL(访问控制列表)，这个列表规定了用户的权限，即限定了特定用户对目标节点可以执行的操作。
（3）节点类型
ZooKeeper中的节点有两种，分别为临时节点和永久节点。节点的类型在创建时即被确定，并且不能改变。
ZooKeeper的临时节点：该节点的生命周期依赖于创建它们的会话。一旦会话结束，临时节点将被自动删除，当然可以也可以手动删除。另外，需要注意是， ZooKeeper的临时节点不允许拥有子节点。
ZooKeeper的永久节点：该节点的生命周期不依赖于会话，并且只有在客户端显示执行删除操作的时候，他们才能被删除。
（4）顺序节点（唯一性的保证）
当创建Znode的时候，用户可以请求在ZooKeeper的路径结尾添加一个递增的计数。这个计数对于此节点的父节点来说是唯一的，它的格式为”%10d”(10位数字，没有数值的数位用0补充，例如”0000000001”)。当计数值大于232-1时，计数器将溢出。
