zookeeper是一个分布式的，开源的分布式应用程序，该程序主要用于管理其他分布式应用程序。其他分布式应用程序可以基于zookeeper实现数据同步，配置维护和命名服务等等。zookeeper是Hadoop的一个子项目，由于在原有的分布式应用系统中，工程师不能很好的使用锁机制，或者基于消息的协调机制不适合在某些应用中使用，因此需要一种可靠的，可扩展的，分布式的，可配置的协调机制来统一系统的状态，Zookeeper的作用就在于此。本文简单介绍Zookeeper的相关名词概念，然后简单介绍其工作原理。
zookeeper概念
- zookeeper主要角色
zookeeper中的角色分类表如下所示：
- zookeeper系统模型
- zookeeper系统设计目的
- 最终一致性：client无论连接到哪个Server，展现给它的是同一个视图，这是zookeeper最重要的特性；
- 可靠性：具有简单、健壮、良好的性能，如果消息Message被一台服务器接受，那么他将被所有的服务器接受；
- 实时性：zookeeper保证client端在一个时间间隔范围内获取到服务器端的更新信息，或者服务器的失效信息。但由于网络延迟等原因，zookeeper无法保证两个客户端能够同时获取到Server端刚更新的信息，如果需要最新数据，应该在读取数据之前调用sync()接口。
- 等待无关性：慢的或者失效的client不得影响快速的client的请求，保证每个client的等待都是有效的；
- 原子性：更新只能成功或者失败，没有中间状态。
- 顺序性：包括全局有序或者片序两种：全局有序是在Server集群中，如果有一台上的消息a在消息b前发布，那么所有Server上的消息a均在消息b前被发布；片序是指客户端的更新顺序与它们被发送的顺序相一致。
- zookeeper相关名词概念
- ZNode：zookeeper树的节点称作ZNode。ZNode会维护一个包含数据信息和ACL(访问控制列表)修改版本号的Stat结构体，这个结构体还包括时间戳字段。版本号和时间戳可以让Zookeeper校验缓存，协调更新。每次修改Znode数据的时候，版本号都会增加。客户端获取数据的同时，也会获得数据的版本号。
- ZNode观察：ZNode是程序员主要访问的实体，客户端可以在znode上设置观察点，客户端对znode的创建、修改、读取等操作会触发观察事件，当观察事件被触发时，Zookeeper向客户端发出一个通知。
- Znode数据存取：存储在每个znode节点上的数据都是原子性的读取和写入。节点的ACL可以控制进行操作的用户。
- 临时节点：zookeeper有临时节点的概念。临时节点在创建他的会话活动期间存在，会话终止的时候，临时节点会被删除，所以临时节点不能有子节点。
- Zookeeper中的时间:zxid,zookeeper事物ID，事物ID是zoookeeper中所有修改的标记次序，如果zxid1<zxid2，那么zxid1修改事件是在zxid2修改事件之前发生的。
- 版本号：对节点的每一次修改都会使得节点的版本号+1，节点版本号有3种：version(znode数据修改的次数)、cversion(znode子节点修改的次数)、aversion(znode ACL修改的次数)
- Zookeeper的Stat结构体
- czxid:创建节点事物的zxid
- mzxid:对znode最近一次修改的事物zxid
- ctime:以距离时间原点的毫秒数表示znode的创建时间
- mtime:以距离时间原点的毫秒数表示znode的最近修改时间
- version:znode数据修改次数
- cversion:znode子节点修改次数
- aversion:znode ACL修改次数
- ephemeralOwner:如果znode是临时节点，则表示创建该znode会话的ID，如果不是临时节点，则为0
- dataLength:znode数据长度
- numChildren:znode子节点个数
- zookeeper观察
zookeeper中的所有读操作：getData()、getChildren()和exists()都会设置一个对znode进行观察的事件。观察事件是在znode数据发生变化时，发送给建立观察的客户 的一次性触发器。
-
- 一次触发：观察事件将在数据发生修改后被触发。比如说，如果客户端对“/znode1”进行里数据读取操作（“getData("/znode1",true)”），然后对“/znode1”上的数据进行了修改操作，或者被删除时，客户端收到“/znode1”的观察事件。如果再次修改“/znode1”的数据，则不会再次触发观察事件，除非客户端再次执行一次读取操作，重新设置新的观察。
- 发送给客户端：zookeeper保证在收到观察事件之前，客户端不会得到自己已经成功修改znode的返回码。即在存在观察事件的前提下，客户端先收到观察事件反馈的结果，然后才能得到自己修改节点数据成功的信息。
zookeeper原理
zookeeper的核心是原子广播，这个机制保证了zookeeper集群之间的数据同步。实现原子广播机制的协议是Zab协议，该协议有两种模式：恢复模式（选leader）和广播模 式（同步模式）。当服务启动或者在leader崩溃后，Zab就进入了恢复模式，当leader被选举出来后，且大多数server与leader完成状态同步后，恢复模式结束，进入同步模式。 同步模式保证了leader和server具有相同的系统状态。
为了保证事物顺序的一致性，zookeeper采用了递增的事物ID号zxid来标识事物。所有的提议（proposal）都在被提出的时候加上了zxid。zxid是一个64二进制位的数字， 他的高32位是epoch，用来标识leader是否发生变化，当一个新的leader被选举出来后，zxid就会有一个新的epoch，标识当前属于那个leader管理，低32位用来计数。
每个Server在工作过程中存在三种状态：
-
- LOOKING:当前Server不知道谁是Leader，正在搜索......
- LEADING:当前Server为Leader
- FOLLOWING:leader已经被选出，当前Server与之同步
- 选主流程
当leader崩溃或者集群启动或者在leader失去大多数follower时，zookeeper进入恢复模式选择出一个新的leader，让所有Server都恢复到一个正确的状态。zookeeper的 选举算法有两种：一种是基于basic paxos，一种基于fast paxos。系统默认选举算法为fast paxos。
- 同步流程
选完leader后，zookeeper就进入了同步过程。
-
- leader等待follower连接
- follower连接leader，将最大的zxid发送给leader
- leader根据follower的zxid确定同步点
- 完成同步后通知follower已经成为update状态
- follower接受到update信息后标识同步过程完成，此时client可以向follower发出服务请求了
zookeeper主流应用场景
- 配置管理
集中式的配置管理在集群应用中是非常常见的，一般商业公司内部都会实现一套集中的配置管理中心，应对不同的集群应用对各自配置信息的不同需求，并且在配置信息发生变化时配置管理中心会及时的通知到集群中的每一台机器。
zookeeper很容易实现这种集群式的配置管理，比如将APP1的所有配置信息配置到znode “/APP1“节点中，APP1的所有机器一启动就对”/APP1“这个节点进行监控（zk.exist("/APP1",true)），并且实现回调方法Watcher，那么在zookeeper上 znode ”/APP1“节点数据发生变化时，Watcher方法将会被执行，每个APP1应用都会得到通知，那 么应用可以通过zk.getData("/APP1",false,null)重新获取最新配置信息。
- 集群管理
集群应用中，我们常常需要让每一台机器知道集群中那些机器是活着的，并且在集群机器因为宕机、网络中断等原因能够不再人工介入的情况下迅速通知到每一台机器。
zookeeper很容易实现这个功能。比如，zookeeper服务端有一个znode叫”/APP1Servers“，那么集群中的每一台机器在启动的时候都在”/APP1Servers“目录下创建一个临时的（EPHEMERAL）节点，比如Server1创建”/APP1Servers/Server1“，Server2创建"/APP1Servers/Server2"，然后Server1和Server2都Watch "/APP1Servers" 这个父节点。当父节点“/APP1Servers"或者父节点下的两个子节点的数据发生变化时，均会出发监控事件并及时反馈给两个客户端（Server1和Server2）。临时的（EPHEMERAL）节点有一个很重要的特性，就是当服务器端和客户端断开时，或者创建该Znode的会话Session过期时，该Znode节点会自动消失。所以，当某台机器宕机或者断开连接时，该机器创建的临时Znode节点就会自动消失，就会触发其他机器建立的Watch，从而其他机器就可以重新获取列表信息，了解当前集群状态。