一、Zookeeper概述
Zookeeper作为Hadoop项目中的一个子项目，是Hadoop集群管理的一个必不可少的模块，它主要用来控制集群中的数据，如它管理Hadoop集群中的NameNode，还有
Hbase中Master Election、Server 之间状态同步等。
Zoopkeeper提供了一套很好的
分布式集群 管理的机制，就是它这种基于层次型的目录树的 数据结构 ，并对树中的节点进行有效管理，从而可以设计出多种多样的分布式的 数据管理模型。Zookeeper并不是用来专门存储数据，它的作用主要是用来维护和监控你存储的数据的状态变化。通过监控这些数据状态的变化，从而可以达到基于数据的集群管理。
二、Zookeeper特性
1、结构简单
类似于文件系统的
树状结构2、单系统镜像
无论客户端连接到哪一个服务器，他将看到相同的、Zookeeper试图
3、
有序性有序的事务编号，客户端的更新顺序与它们被发送的顺序相一致
4、原子性
更新操作要么成功要么失败，没有第三种结果
二、Zookeeper工作原理
Zookeeper的核心是原子广播，这个机制保证了各个server之间的同步。实现这个机制的协议叫做Zab协议。Zab协议有两种模式，它们分别是恢复模式(选主)和广播模式(同步)。当服务启动或者在领导者崩溃后，Zab就进入了恢复模式，当领导者被选举出来，且大多数server的完成了和leader的状态同步以后，恢复模式就结束了。状态同步保证了leader和server具有相同的系统状态。
为了保证事务的顺序一致性，zookeeper采用了递增的事务id号（zxid）来标识事务。所有的提议（proposal）都在被提出的时候加上了zxid。实现中zxid是一个64位的数字，它高32位是epoch用来标识leader关系是否改变，每次一个leader被选出来，它都会有一个新的epoch，标识当前属于那个leader的统治时期。低32位用于递增计数。
每个Server在工作过程中有三种状态：LOOKING：当前Server不知道leader是谁，正在搜寻LEADING：当前Server即为选举出来的leaderfollowing：leader已经选举出来，当前Server与之同步
三、Leader工作流程
1、Leader主要有三个功能：
a.恢复数据
b.维持与Follower的心跳，接收Follower请求并判断Follower的请求消息类型
c.Follower的消息类型主要有PING消息、REQUEST消息、ACK消息、REVALIDATE消息，根据不同的消息类型，进行不同的处理
四、Follower工作流程
1、Follower主要有四个功能:
a、向Leader发送请求（PING消息、REQUEST消息、ACK消息、REVALIDATE息）
b、接收Leader消息并进行处理
c、接收Client的请求，如果为写请求，发送给Leader进行投票返回Client结果
2、Follower的消息循环处理如下几种来自Leader的消息:
a、PING消息： 心跳消息
b、PROPOSAL消息：Leader发起的提案，要求Follower投票
c、COMMIT消息：服务器端最新一次提案的信息
d、UPTODATE消息：表明同步完成
e、REVALIDATE消息：根据Leader的REVALIDATE结果，关闭待revalidate的session还是允许其接受消息
f、SYNC消息：返回SYNC结果到
客户端，这个消息最初由客户端发起，用来强制得到最新的更新。
五、Zookeeper的目录结构
1、每个znode的名称都是绝对路径名来组成的，如“/app1/p_1”等。
2、读取或写入znode中的数据都是原子操作，read会获取znode中的所有字节, write会整个替换znode中的信息.每个znode都包含一个
访问控制列表(ACL)以约束该节点的访问者和权限。
3、有些znode是临时节点，临时节点在创建它的session的生命周期内存活, 当其session终止时，此类节点将会被删除。
4、zookeeper提供znode监听器的概念. Client可以在某个znode上设置监听器以监听该znode的变更. 当znode有变更时, 这些Client将会收到通知,并执行预先敲定好的函数。
六、Zookeeper的节点
1、每个节点在zookeeper中叫做znode,并且其有一个唯一的路径标识
2、znode有三种类型，临时的（ EPHEMERAL ）、持久的（ PERSISTENT ）和有序的 (SEQUENTIAL)
3、znode的类型在创建时确定并且之后不能再修改znode可以包含数据和子节点，但是EPHEMERAL类型的节点不能有子节点
4、znode中的数据可以有多个版本，比如某一个路径下存有多个数据版本，那么查询这个路径下的数据就需要带上版本
5、节点不支持部分读写，而是一次性完整读写
6、短暂znode的客户端会话结束时，zookeeper会将该短暂znode删除，短暂znode不可以有子节点
7、持久znode不依赖于客户端会话，只有当客户端明确要删除该持久znode时才会被删除
8、客户端应用可以在节点上设置监视器
七、观察(watcher)
Watcher 在 zookeeper 是一个核心功能，Watcher 可以监控目录节点的数据变化以及子目录的变化，一旦这些状态发生变化，服务器就会通知所有设置在这个
目录节点上的 Watcher，从而每个客户端都很快知道它所关注的目录节点的状态发生变化，而做出相应的反应
八、Zookeeper的读写机制
zookeeper是一个由多个server组成的集群
一个leader，多个follower
每个server保存一份数据副本
全局数据一致
分布式读写
更新请求转发，由leader实施
更新请求顺序进行，来自同一个client的更新请求按其发送顺序依次执行
数据更新原子性，一次数据更新要么成功，要么失败
全局唯一数据视图，client无论连接到哪个server，数据视图都是一致的
实时性，在一定事件范围内，client能读到最新数据
九、Zookeeper的API接口
String create(String path, byte[] data, List<ACL> acl, CreateMode createMode) //创建一个节点
void delete(String path, int version) //删除一个节点
void setData(String path, byte[] data, int version) //设置一个节点的数据
Boolean exists(String path, boolean watch) //查看一个节点的状况，如果没有返回null,可注入watcher
byte[] getData(String path, boolean watch, Stat stat) //获取一个节点的数据, 可注入watcher
List<String> getChildren(String path, boolean watch) //获取一个节点的子节点, 可注入watcher
void addAuthInfo(String scheme, byte[] auth) //设置权限
Stat setACL(String path, List<ACL> acl, int version) //设置权限
List<ACL> getACL(String path, Stat stat) //获取权限列表 十、配置管理
配置的管理在分布式应用环境中很常见，例如同一个应用系统需要多台 PC Server运行，但是它们运行的应用系统的某些配置项是相同的，如果要修改这些相同的配置项，那么就必须同时修改每台运行这个应用系统的 PC Server，这样非常麻烦而且容易出错。
将配置信息保存在 Zookeeper 的某个目录节点中，然后将所有需要修改的应用机器监控配置信息的状态，一旦配置信息发生变化，每台应用机器就会收到 Zookeeper 的通知，然后从 Zookeeper 获取新的配置信息应用到系统中。
十一、命名服务
分布式应用中，通常需要有一套完整的命名规则，既能够产生唯一的名称又便于人识别和记住，通常情况下用
树形的名称结构是一个理想的选择，树形的名称结构是一个有层次的目录结构，既对人友好又不会重复。
Name Service 是 Zookeeper 内置的功能，只要调用 Zookeeper 的 API 就能实现