zookeeper 是什么？zookeeper 都有哪些功能？

zookeeper 是什么？

ZooKeeper由雅虎研究院开发，是Google Chubby的开源实现，后来托管到Apache，于2010年11月正式成为Apache的顶级项目。
ZooKeeper是一个经典的分布式数据一致性解决方案，致力于为分布式应用提供一个高性能、高可用，且具有严格顺序访问控制能力的分布式协调服务。
分布式应用程序可以基于ZooKeeper实现数据发布与订阅、负载均衡、命名服务、分布式协调与通知、集群管理、Leader选举、分布式锁、分布式队列等功能。

在Zookeeper的官网上有这么一句话：ZooKeeper is a centralized service for maintaining configuration information, naming, providing distributed synchronization, and providing group services. 

这大概描述了Zookeeper主要可以干哪些事情：配置管理，名字服务，提供分布式同步以及集群管理。那这些服务又到底是什么呢？我们为什么需要这样的服务？我们又为什么要使用Zookeeper来实现呢，使用Zookeeper有什么优势？接下来我会挨个介绍这些到底是什么，以及有哪些开源系统中使用了。

zookeeper 都有哪些功能？

统一命名服务(naming)

分布式应用中,通常需要有一套完整的命名规则,既能产生唯一的命名又便于识别和记住,通常情况下用树形的结构是一个理想的选择,属性的名称结构是一个有层次的目录结构,既对人友好又不会重复,说到这里你可能想到JNDO没错Zookeeper的Name Service与JNDI能够完成的功能是差不多的,他们都是具有层次的目录结构关联到一定资源上,但是Zookeeper的NameService更加是广泛意义上的关联,也许你并不需要将名称关联到特定资源上,你可能只需要一个不会重复的名称,就想数据库中产生唯一的数字主键一样.
NameService已经是Zookeeper内置的功能,你只要调用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是一个分布式协调服务。这样我们就可以利用Zookeeper来协调多个分布式进程之间的活动。比如在一个分布式环境中，为了提高可靠性，我们的集群的每台服务器上都部署着同样的服务。但是，一件事情如果集群中的每个服务器都进行的话，那相互之间就要协调，编程起来将非常复杂。而如果我们只让一个服务进行操作，那又存在单点。通常还有一种做法就是使用分布式锁，在某个时刻只让一个服务去干活，当这台服务出问题的时候锁释放，立即fail over到另外的服务。这在很多分布式系统中都是这么做，这种设计有一个更好听的名字叫Leader Election(leader选举)。比如HBase的Master就是采用这种机制。但要注意的是分布式锁跟同一个进程的锁还是有区别的，所以使用的时候要比同一个进程里的锁更谨慎的使用。

 

参考链接：什么是zookeeper