ZooKeeper是用于分布式系统的高性能协调服务，通过简单的接口提供了命名服务，配置管理，同步和组服务等常用服务。 ZooKeeper是分布式的，开放源码的，是Google的Chubby一个开源的实现，是Hadoop和Hbase的重要组件。
角色：
Zookeeper分为服务端和客户端，客户端连接到服务端的某台机器上，通过维护一个TCP连接发送请求，接受请求，发送心跳和获取观察的事件。如果该连接中断，客户端尝试连接到其他服务端。启动服务端集群后，集群中的服务器首先选举一个Leader，然后进入工作，当Leader机器崩溃后，剩下正常的机器会继续选举，Leader的作用是保证数据的一致性。
在ZooKeeper服务侧集群当中有两种角色Leader和Follower。Leader可以接受client请求，也接收其他Server转发的写请求，负责更新系统状态。 Follower也可以接收client请求，如果是写请求将转发给Leader来更新系统状态，读请求则由Follower的内存数据库直接响应。在zk的3.3.3版本以后，又添加了一种新角色Observer。Observer的作用同Follower类似，唯一区别就是它不参与选主过程。
特性：
1.最终一致性：客户端无论连接到哪个服务端，获取到的数据都一致。
2.实时性：客户端在一个时间范围内总能获取到服务端的更新信息或失效信息。
3.原子性：数据的更新只能是成功的或失败的。
4.顺序性：所以数据的更新请求都是单调有序的。
数据模型：
Zookeeper数据模型类似文件系统的目录树结构，特点如下：
1.每个节点（znode）被其所在的路径唯一标识，如/Apps/App1。
2.znode可以存储数据，EPHEMERAL类型节点没有子节点。
3.znode有版本，即znode中的数据有版本。
4.znode名称可以自动编号，即如果App1存在，再创建的节点会自动命名为App2
5.临时znode在失去连接的时候自动删除。
6.客户端服务端保持长连接，一个连接状态称为session，session失效了，临时节点就会自动删除。
7.任何znode的变化都可被监控，包括数据的变化和子节点的变化。当监控到变化，监控者（客户端）被通知，执行回调方法。
工作原理：
Zookeeper核心机制是原子广播，它保证了个服务端之间的数据同步。Zab协议保证了这一点。
Zookeeper有两种工作模式：恢复模式和广播模式。当服务启动时和Leader崩溃后进入恢复模式，恢复模式下Zookeeper进行leader选举，耗时在200ms内。当Leader被选举出来，且大多数服务器与Leader完成诗句同步后，ZK进入广播模式。为了保证事务的顺序一致性，ZK采用了递增的事务ID（zxid）来标识事务。
所有的提议都会被加上zxid，zxid为64位的数字，高32位是epoch用来标识leader是否改变的每一次leader选举出来都有一个新的epoch。zxid低32位用来递增计数。
每个服务器在工作中有3个状态：
Looking：当前服务器不知道谁是leader，搜索中。
Leading：当前服务器即为leader，领导中。
Following：当前服务器不是leader，正在与leader同步中。
同步流程：
1.leader等待服务器连接。
2.follower连接Leader，将最大的zxid发送给leader。
3.Leader根据follower的zxid确定同步点。
4.同步后通知follower成为uptodate状态。
5.follower收到uptodate消息后，同步完成。
leader工作流程：
leader功能：恢复数据，保持心跳，相应消息
leader可响应的消息有PING，REQUEST，ACK和REVALIDATE
PING即心跳消息，REQUEST为follower发送的提议（写请求或同步请求），ACK是follower对提议的回复，超过半数的follower通过，则commit。REVALIDATE为延长session的请求。
follower工作流程：
向leader发送请求并响应。
接受client请求并响应，接受写请求时发送给leader处理。
follower可响应的请求：
PING：发送心跳信息
PROPOSAL：leader发起的提案，follower投票
Commit：提议被commit
UPTODATE：同步完成
REVALIDATE：延长session的响应
SYNC：客户端发起，强制返回更新的数据
end