李战磊专栏

ZooKeeper的功能特性是通过ZooKeeper配置文件（Zoo.cfg）来进行控制管理的。这样的手机其实有其自身的原因。通过前面对ZooKeeper的配置可以看出，在ZooKeeper集群进行配置的时候，他的配置文档是完全相同的(对于集群伪分布式来说，只有很少的部分是不同的)。这样的配置方式使得在部署ZooKeeper服务的时候非常方便。如果服务器使用不同的配置文件，必须要确保不同配置文件中

本篇包括以下内容：1、ZooKeeper的数据模型2、ZooKeeper会话及状态3、ZooKeeper watches4、ZooKeeper ACL5、ZooKeeper的一致性保证

为更好了解Zookeeper，对书本和网上资料汇总本章首先介绍如何在不同的环境下安装并配置ZooKeeper服务、然后具体介绍如何通过ZooKeeper配置文件对ZooKeeper进行配置管理；最后介绍如何在不同环境下启动ZooKeeper服务。安装ZooKeeperZooKeeper有不同的运行环境，包括，单机环境、集群环境和集群伪分布式环境。这里，我们将分别介绍不同环境下如何安

分布式锁，这个主要得益于ZooKeeper为我们保证了数据的强一致性。锁服务可以分为两类，一个是保持独占，另一个是控制时序。所谓保持独占，就是所有试图来获取这个锁的客户端，最终只有一个可以成功获得这把锁。通常的做法是把zk上的一个znode看作是一把锁，通过create znode的方式来实现。所有客户端都去创建 /distribute_lock 节点，最终成功创建的那个客户端也即拥有了这把锁。控制时序，就是所有视图来获取这个锁的客户端，最终都是会被安排执行，只是有个全局时序了。做法和上面基本类似，只是这里

拿董老师的案例：设计一个基于 Zookeeper 的 Hadoop 配置管理服务， 该服务由两个功能模块组成：1） 配置文件更新组件 HadoopConfigUpdater （管理员修改配置文件后，执行该组件，将数据写入 Zookeeper） ，可将管理员修改的 Hadoop conf 目录打包成 conf.zip，并写入 Zookeeper 中/conf 节点（znode）中；2） 客户端监听者 HadoopConfigWatcher（运行在各个节点上） ，可监听/conf 节点，一旦得知节点数

集群机器监控：这通常用于那种对集群中机器状态，机器在线率有较高要求的场景，能够快速对集群中机器变化作出响应。这样的场景中，往往有一个监控系统，实时检测集群机器是否存活。过去的做法通常是：监控系统通过某种手段（比如ping）定时检测每个机器，或者每个机器自己定时向监控系统汇报“我还活着”。 这种做法可行，但是存在两个比较明显的问题：1）集群中机器有变动的时候，牵连修改的东西比较多。2）有一定的延时

Leader选举又称为master选举是zookeeper中最为经典的应用场景了。 在分布式环境中，相同的业务应用分布在不同的机器上，有些业务逻辑（例如一些耗时的计算，网络I/O处理），往往只需要让整个集群中的某一台机器进行执行，其余机器可以共享这个结果，这样可以大大减少重复劳动，提高性能，于是这个Leader选举便是这种场景下的碰到的主要问题。 ZooKeeper需要在所有的服务(可理解为服务器)中选举出一个Leader，然后让这个Leader来负责管理集群。此时，集群中的其他服务器则成了此Leade

1、下载zookeeper-3.4.*.tar.gz源码包2、新建一个java Project，例如TestProject3、看到里面的zookeeper-3.4.*/recipes/lock目录，按照源码package路径paste到TestProject。4、下载zookeeper的范例lock

（1）Zookeeper快速搭建和客户端使用 (2)应用场景（3）编程与应用（4）扩展阅读