统一命名服务(naming)
分布式应用中,通常需要有一套完整的命名规则,既能狗产生唯一的命名又便于认识别和记住,通常情况下用树形的结构是一个理想的选择,属性的名称结构是一个有层次的目录结构,既对人友好又不会重复,说到这里你可能xiangdao`想到JNDO没错Zookeeper的Name Service与JNDI能够完成的功能是差不多的,他们都是酱油层次的目录结构关联到一定资源上,dansh但是Zookeeper的NameService更加是广泛意义上的关联,也许你并不需要将名称关联到特定资源上,你可能只需要一个不会重复的名称,就想数据库中产生唯一的数字主键一样.
NameService已经是Zookeeper内置的功能,nizh你只要调用Zookeeper的API就能实现,如调用create接口就可以很容易的创建一个目录节点.
配置管理
配置管理的在分布式应用环境下很常见,例如同一个应用系统需要多台PC Server运行,但是他们运行的应用系统的某些配置是相同的,如果要修改这个相同的配置项,那么就必须同时修改每台运行这个系统的PC Server这样非常麻烦而且容易出错.
像这样的配置信息完全可以交给Zookeeper来管理,将配置信息保存在Zookeeper的某个目录节点中,然后将所有需要修改的应用及其监控配置信息的状态,一旦配置信息发生变化,每台应用及其就会收到ZooKeeper的通知,然后从Zookeeper的通知,然后从Zookeeper获取新的配置信息应用到系统中
集群管理
Zookeeper能够很容易的实现集群管理的功能,如有多台Server组成一个服务集群,那么必须要一个总管知道当前及权重每台机器的服务状态,一旦有机器不能提供服务,集群中其他集群必须知道,从而做出调整重新分配服务政策.同样增加集群的服务能力时,就会增加一台或者多台server,同样也必须让总管知道.
Zookeeper不仅能够帮你维护当前的集群中机器的服务状态,而且能够帮你选出一个'总管',让这个总管来管理集群,这就是Zookeeper的另一个功能 Leader Election
它们的实现方式都是在 Zookeeper 上创建一个 EPHEMERAL 类型的目录节点，然后每个 Server 在它们创建目录节点的父目录节点上调用 getChildren(String path, boolean watch) 方法并设置 watch 为 true，由于是 EPHEMERAL 目录节点，当创建它的 Server 死去，这个目录节点也随之被删除，所以 Children 将会变化，这时 getChildren上的 Watch 将会被调用，所以其它 Server 就知道已经有某台 Server 死去了。新增 Server 也是同样的原理。
Zookeeper 如何实现 Leader Election，也就是选出一个 Master Server。和前面的一样每台 Server 创建一个 EPHEMERAL 目录节点，不同的是它还是一个 SEQUENTIAL 目录节点，所以它是个 EPHEMERAL_SEQUENTIAL 目录节点。之所以它是 EPHEMERAL_SEQUENTIAL 目录节点，是因为我们可以给每台 Server 编号，我们可以选择当前是最小编号的 Server 为 Master，假如这个最小编号的 Server 死去，由于是 EPHEMERAL 节点，死去的 Server 对应的节点也被删除，所以当前的节点列表中又出现一个最小编号的节点，我们就选择这个节点为当前 Master。这样就实现了动态选择 Master，避免了传统意义上单 Master 容易出现单点故障的问题。
对列管理
Zookeeper 可以处理两种类型的队列：
1.当一个队列的成员都聚齐时，这个队列才可用，否则一直等待所有成员到达，这种是同步队列。
2.队列按照 FIFO 方式进行入队和出队操作，例如实现生产者和消费者模型。
同步队列用 Zookeeper 实现的实现思路如下：
创建一个父目录 /synchronizing，每个成员都监控标志（Set Watch）位目录 /synchronizing/start 是否存在，然后每个成员都加入这个队列，加入队列的方式就是创建 /synchronizing/member_i 的临时目录节点，然后每个成员获取 / synchronizing 目录的所有目录节点，也就是 member_i。判断 i 的值是否已经是成员的个数，如果小于成员个数等待 /synchronizing/start 的出现，如果已经相等就创建 /synchronizing/start。
