ZooKeeper是一个分布式的，开放源码的分布式应用程序协调服务，它包含一个简单的原语集，分布式应用程序可以基于它实现同步服务，配置维护和命名服务等。在分布式应用中，由于工程师不能很好地使用锁机制，以及基于消息的协调机制不适合在某些应用中使用，因此需要有一种可靠的、可扩展的、分布式的、可配置的协调机制来统一系统的状态。Zookeeper的目的就在于此。
角色：
1、Leader（领导者）：负责进行投票的发起和决议，更新系统状态
2、Learner（学习者）：包含Follower（跟随者）和Observer（观察者）
Follower：接收客户端请求并向客户端返回结果，在选主过程中参与投票
Observer：接收客户端连接，将写请求转发给Leader节点。但Observer不参与投票，只同步leader的状态。其目的是为了扩展系统，提高读取速度
3、Client（客户端）：请求发起方
系统模型：
设计目的：
1、最终一致性：client不论连接到哪个server，展示给它都是同一个视图。这是Zookeeper最重要的性能。
2、可靠性：具有简单、健壮、良好的性能，如果消息被一台服务器接受，那么它将被所有的服务器接受。
3、实时性：Zookeeper保证客户端将在一个时间间隔范围内获得服务器的更新信息，或者服务器失效的信息。但由于网络延时等原因，Zookeeper不能保证两个客户端能同时得到刚更新的数据。如果需要最新数据，应该在读数据之前调用sync()接口。
4、等待无关(wait-free)：慢的或失效的client不得干预快速的client的请求，使得每个client都能有效的等待。
5、原子性：更新只能成功或失败，没有中间状态。
6、顺序性：包括全局有序和偏序两种。全局有序指如果在一台服务器上消息a在消息b前发布，则在所有的Server上消息a都在消息b前被发布；偏序是指如果一个消息b在消息a后被同一个发送者发布，a必将排在b前面。
工作原理：
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即为选举出来的Leader
FOLLOWING：Leader已经选举出来，当前Server与之同步