（一）、ZooKeeper介绍

ZooKeeper介绍

       ZooKeeper是一个开源的分布式服务框架，它是ApacheHadoop项目的一个子项目，主要用来解决分布式应用场景中存在的一些问题，如：统一命名服务、状态同步服务、集群管理、分布式应用配置管理等，它支持Standalone模式和分布式模式，在分布式模式下，能够为分布式应用提供高性能和可靠地协调服务，而且使用ZooKeeper可以大大简化分布式协调服务的实现，为开发分布式应用极大地降低了成本。

      ZooKeeper对分布式开发带来很多便利，利用ZK的独有特性巧妙地解决了很多难题，很多分布式技术用到ZooKeeper或多或少特性，尤其是新生代分布式技术几乎都会依赖ZooKeeper特性，如HBase、火爆的Storm。

• ZooKeeper是一个分布式的，开放源码的分布式应用程序协调服务，是Google的Chubby一个开源的实现，是Hadoop和Hbase的重要组件。它是一个为分布式应用提供一致性服务的软件，提供的功能包括：配置维护、域名服务、分布式同步、组服务等。
• ZooKeeper的目标就是封装好复杂易出错的关键服务，将简单易用的接口和性能高效、功能稳定的系统提供给用户。
• ZooKeeper包含一个简单的原语集，提供Java和C的接口。
• ZooKeeper代码版本中，提供了分布式独享锁、选举、队列的接口，代码在zookeeper-3.4.3\src\recipes。其中分布锁和队列有Java和C两个版本，选举只有Java版本。

ZooKeeper应用场景

集群管理

• Storm集群：ZooKeeper作为nimbus（master）和supervisor（slave）的中间枢纽，保存Storm集群和作业的所有信息，并肩负nimbus和supervisor的全部通信。
• HBase集群：HBase集群：ZooKeeper作为“协调器”，为HBase提供稳定服务和failover机制，HRegionServer也会把自己作为以Ephemeral方式注册到ZooKeeper中，使得HMaster可以随时感知到各个HRegionServer的健康状态（可用于监控RegionServer）。此外，ZooKeeper也避免了HMaster的单点问题。

应用三大块：

• Storm应用开发，Storm集群监控
• MapReduce应用开发
• HBase开发

分布式配置管理

   发布和订阅即所谓的配置管理，顾名思义就是将数据发布到ZK节点上，供订阅者动态获取数据，实现配置信息的集中式管理和动态更新。例如：全局的配置信息，地址列表等就非常适合使用。

   配置的管理在分布式应用环境中很常见，例如同一个应用系统需要多台PC Server运行，但是它们运行的应用系统的某些配置项是相同的，如果要修改这些相同的配置项，那么就必须同时修改每台运行这个应用系统的PC Server ，这样非常麻烦而且容易出错。像 这样的配置信息完全可以交给 ZooKeeper 来管理，将配置信保存在ZooKeeper 的某个目录节点中，然后将所有需要修改的应用机器监控配置信息的状态，一旦配置信息发生变化，每台应用机器就会收到 ZooKeeper 的通知，然后从 ZooKeeper 获取新的配置信息应用到系统中。

  

统一命名服务

       Name Service:这个主要是作为分布式命名服务，通过调用ZK的Create Node API,能够和容易的创建一个全局的Path，这个Path就可以作为一个名称。 

      分布式应用中，通常需要有一套完整的命名规则，既能够产生唯一的名称又便于人识别和记住，通常情况下用树形的名称结构是一个理想的选择，树形的名称结构是一个有层次的目录结构，既对人友好又不会重复。说到这里你可能想到了 JNDI，没错 Zookeeper 的 Name Service 与 JNDI 能够完成的功能是差不多的，它们都是将有层次的目录结构关联到一定资源上，但是 Zookeeper 的 Name Service 更加是广泛意义上的关联，也许你并不需要将名称关联到特定资源上，你可能只需要一个不会重复名称，就像数据库中产生一个唯一的数字主键一样。

分布式通知\协调

        ZooKeeper中特有Watcher注册与异步通知机制，能够很好的实现分布式环境下不同系统之间的通知协调，实现对数据变更的实时处理。处理方法通常是不同系统对应ZK上的一个ZNode进行注册，监听ZNode的变化（包括ZNode本身内容以及子节点的），其中有个系统Update了ZNode，那么另外一个系统就能够收到通知，并做相应处理。  

分布式锁

      分布式锁，这个主要得益于ZooKeeper为我们保证了数据的强一致性，即用户只要完全相信每时每刻，ZK集群中任意节点（一个ZK Server）上的相同ZNode的数据是一定相同的。锁服务可以分为两类，一个保持独占，另一个控制时序。

     共享锁在同一个进程中很容易实现，但是在跨进程或者在不同 Server 之间就不好实现了。Zookeeper 却很容易实现这个功能，实现方式也是需要获得锁的 Server 创建一个 EPHEMERAL_SEQUENTIAL 目录节点，然后调用 getChildren方法获取当前的目录节点列表中最小的目录节点是不是就是自己创建的目录节点，如果正是自己创建的，那么它就获得了这个锁，如果不是那么它就调用 exists(String path, boolean watch) 方法并监控 Zookeeper 上目录节点列表的变化，一直到自己创建的节点是列表中最小编号的目录节点，从而获得锁，释放锁很简单，只要删除前面它自己所创建的目录节点就行了。

分布式队列

      队列方面，一种常规的先进先出队列，另一种等到队列成员聚集之后才统一顺序执行。
      对于第二种先进先出队列，增加分布式锁以控制时序场景。

      同步队列用 Zookeeper 实现的实现思路如下：
      创建一个父目录 /synchronizing，每个成员都监控标志（Set Watch）位目录 /synchronizing/start 是否存在，然后每个成员都加入这个队列，加入队列的方式就是创建 /synchronizing/member_i 的临时目录节点，然后每个成员获取 / synchronizing 目录的所有目录节点，也就是 member_i。判断 i 的值是否已经是成员的个数，如果小于成员个数等待 /synchronizing/start 的出现，如果已经相等就创建 /synchronizing/start。