Zookeeper的系列使用场景

今天就来谈一下ZK的使用场景，学好一门技术但是不知道怎么在生产环境下使用，那也是多学无益，早期我开始接触Zookeeper的是在开发Dubbo微服务的时候使用的，现在zookeeper已经大规模的在hadoop中运用。

（1）分布式应用中，通常需要有一套完整的命名规则，既能够产生唯一的名称又便于人识别和记住，通常情况下用树形的名称结构是一个理想的选择，树形的名称结构是一个有层次的目录结构，既对人友好又不会重复。

Name Service 是 Zookeeper 内置的功能，只要调用 Zookeeper 的 API 就能实现

（1）配置的管理在分布式应用环境中很常见，例如同一个应用系统需要多台 PC Server 运行，但是它们运行的应用系统的某些配置项是相同的，如果要修改这些相同的配置项，那么

就必须同时修改每台运行这个应用系统的PC Server，这样非常麻烦而且容易出错。

（2）将配置信息保存在 Zookeeper 的某个目录节点中，然后将所有需要修改的应用机器监控配置信息的状态，一旦配置信息发生变化，每台应用机器就会收到Zookeeper 的通知，

然后从 Zookeeper 获取新的配置信息应用到系统中。

（3）注意：Zookeeper很容易实现这种集中式的配置管理，比如将APP1的所有配置配置到/APP1 znode下，APP1所有机器一启动就对/APP1这个

节点进行监控(zk.exist(“/APP1″,true)),并且实现回调方法 Watcher，那么在zookeeper上/APP1 znode节点下数据发生变化的时候，

每个机器都会收到通知，Watcher方法将会被执行，那么应用再取下数据即可 (zk.getData(“/APP1″,false,null));

（1）Zookeeper 能够很容易的实现集群管理的功能，如有多台Server 组成一个服务集群，那么必须要一个“总管”知道当前集群中每台机器的服务状态，一旦有机器

不能提供服务，集群中其它集群必须知道，从而做出调整重新分配服务策略。同样当增加集群的服务能力时，就会增加一台或多台Server，同样也必须让“总管”知道。

Zookeeper 不仅能够维护当前的集群中机器的服务状态，而且能够选出一个“总管”，让这个总管来管理集群，这就是Zookeeper 的另一个功能 LeaderElection

（2）Zookeeper 如何实现 LeaderElection，也就是选出一个 MasterServer；另外有一个应用场景就是集群选master,一旦master挂掉能够马上

能从slave中选出一个master,实现步骤和前者一样，只是机器在启动的时候在APP1SERVERS创建的节点

类型变为EPHEMERAL_SEQUENTIAL类型，这样每个节点会自动被编号。

（3）规定编号最小的为master,所以当我们对SERVERS节点做监控的时候，得到服务器列表，只要所有集群机器逻辑认为最小编号节点为master，

那么master就被选出，而这个master宕机的时候，相应的znode会消失，然后新的服务器列表就被推送到客户端，然后每个节点逻辑认为最小编号节点为master，

这样就做到动态master选举。

（1）共享锁在同一个进程中很容易实现，但是在跨进程或者在不同 Server 之间就不好实现了。Zookeeper 却很容易实现这个功能，实现方式也是需要获得锁的

Server 创建一个 EPHEMERAL_SEQUENTIAL目录节点，然后调用 getChildren方法获取当前的目录节点列表中最小的目录节点是不是就是自己创建的目录节点，

如果正是自己创建的，那么它就获得了这个锁，如果不是那么它就调用exists(String path, boolean watch) 方法并监控 Zookeeper上目录节点列表的变化，

一直到自己创建的节点是列表中最小编号的目录节点，从而获得锁，释放锁很简单，只要删除前面它自己所创建的目录节点就行了。

（1）Zookeeper 作为Hadoop 项目中的一个子项目，是Hadoop 集群管理的一个必不可少的模块，它主要用来控制集群中的数据，如它管理Hadoop 集群

中的NameNode，还有 Hbase 中 MasterElection、Server 之间状态同步等。

（2）Zoopkeeper 提供了一套很好的分布式集群管理的机制，就是它这种基于层次型的目录树的数据结构，并对树中的节点进行有效管理，从而可以

设计出多种多样的分布式的数据管理模型