zookeeper

ZooKeeper是Hadoop Ecosystem中非常重要的组件，它的主要功能是为分布式系统提供一致性协调(Coordination)服务，与之对应的Google的类似服务叫Chubby。今天这篇文章分为三个部分来介绍ZooKeeper，第一部分介绍ZooKeeper的基本原理，第二部分介绍ZooKeeper提供的Client API的使用，第三部分介绍一些ZooKeeper典型的应用场景。

ZooKeeper基本原理

1. 数据模型

如上图所示，ZooKeeper数据模型的结构与Unix文件系统很类似，整体上可以看作是一棵树，每个节点称做一个ZNode。每个ZNode都可以通过其路径唯一标识，比如上图中第三层的第一个ZNode, 它的路径是/app1/c1。在每个ZNode上可存储少量数据(默认是1M, 可以通过配置修改, 通常不建议在ZNode上存储大量的数据)，这个特性非常有用，在后面的典型应用场景中会介绍到。另外，每个ZNode上还存储了其Acl信息，这里需要注意，虽说ZNode的树形结构跟Unix文件系统很类似，但是其Acl与Unix文件系统是完全不同的，每个ZNode的Acl的独立的，子结点不会继承父结点的，关于ZooKeeper中的Acl可以参考之前写过的一篇文章《说说Zookeeper中的ACL》。

2.重要概念 
2.1 ZNode
前文已介绍了ZNode, ZNode根据其本身的特性，可以分为下面两类：

• Regular ZNode: 常规型ZNode, 用户需要显式的创建、删除
• Ephemeral ZNode: 临时型ZNode, 用户创建它之后，可以显式的删除，也可以在创建它的Session结束后，由ZooKeeper Server自动删除

ZNode还有一个Sequential的特性，如果创建的时候指定的话，该ZNode的名字后面会自动Append一个不断增加的SequenceNo。

2.2 Session
Client与ZooKeeper之间的通信，需要创建一个Session，这个Session会有一个超时时间。因为ZooKeeper集群会把Client的Session信息持久化，所以在Session没超时之前，Client与ZooKeeper Server的连接可以在各个ZooKeeper Server之间透明地移动。

在实际的应用中，如果Client与Server之间的通信足够频繁，Session的维护就不需要其它额外的消息了。否则，ZooKeeper Client会每t/3 ms发一次心跳给Server，如果Client 2t/3 ms没收到来自Server的心跳回应，就会换到一个新的ZooKeeper Server上。这里t是用户配置的Session的超时时间。

2.3 Watcher
ZooKeeper支持一种Watch操作，Client可以在某个ZNode上设置一个Watcher，来Watch该ZNode上的变化。如果该ZNode上有相应的变化，就会触发这个Watcher，把相应的事件通知给设置Watcher的Client。需要注意的是，ZooKeeper中的Watcher是一次性的，即触发一次就会被取消，如果想继续Watch的话，需要客户端重新设置Watcher。这个跟epoll里的oneshot模式有点类似。

3. ZooKeeper特性 
3.1 读、写(更新)模式
在ZooKeeper集群中，读可以从任意一个ZooKeeper Server读，这一点是保证ZooKeeper比较好的读性能的关键；写的请求会先Forwarder到Leader，然后由Leader来通过ZooKeeper中的原子广播协议，将请求广播给所有的Follower，Leader收到一半以上的写成功的Ack后，就认为该写成功了，就会将该写进行持久化，并告诉客户端写成功了。

3.2 WAL和Snapshot
和大多数分布式系统一样，ZooKeeper也有WAL(Write-Ahead-Log)，对于每一个更新操作，ZooKeeper都会先写WAL, 然后再对内存中的数据做更新，然后向Client通知更新结果。另外，ZooKeeper还会定期将内存中的目录树进行Snapshot，落地到磁盘上，这个跟HDFS中的FSImage是比较类似的。这么做的主要目的，一当然是数据的持久化，二是加快重启之后的恢复速度，如果全部通过Replay WAL的形式恢复的话，会比较慢。

3.3 FIFO
对于每一个ZooKeeper客户端而言，所有的操作都是遵循FIFO顺序的，这一特性是由下面两个基本特性来保证的：一是ZooKeeper Client与Server之间的网络通信是基于TCP，TCP保证了Client/Server之间传输包的顺序；二是ZooKeeper Server执行客户端请求也是严格按照FIFO顺序的。

3.4 Linearizability
在ZooKeeper中，所有的更新操作都有严格的偏序关系，更新操作都是串行执行的，这一点是保证ZooKeeper功能正确性的关键。

 

4 zookeeper流程

4.1 发现

1.准leader收到过半的follower的高32位zxid，并将其加一

2.准leader将高32位的zxid+1，发送给follower，并过半的follower将自己的高32位zxid更新为准leader的高32位zxid，并将follower的事务集合反回给leader，从中选取一个follower

4.2同步

1.leader将选取的follower的高zxid和事务集合发送给follower

2.follower同步leader的状态并相应

3.leader commit

4.3广播

1.leader接收新的事务，广播到follower

2.follower根据先后顺序执行操作，并相应

3.leader commit

5.应用场景

1.配置中心

向znode建立app名称的节点，并在其节点创建子节点如数据库，缓存，队列的配置信息的节点，当项目启动时自动加载配置信息，并创建监听器，监听znode的子节点数据变化

2.悲观锁

由于zookeeper有一种非排序的节点模型，如果存在该节点，则不能成功创建，像数据库id不可重复似的，因此这种机制可以用于集群调度。当成功创建节点时可以执行调度并删除节点，而节点创建不成功时，注册该节点的监听器，当节点删除时，在执行操作

3.乐观锁

由于zookeeper有一种排序的节点模型，如数据库id是自增的情况，因此这种机制可以用于消息顺序执行。先创建一系列的子节点，选择节点编号最小的执行操作并删除节点，其他未能执行的创建节点注册该列表节点变化的监听器，当变化时在执行操作。但是由于在集群规模达到一定规模时，这种机制会出现羊群效应，因此在创建监听器时，应该监听比自己序号小一的节点变化