ZooKeeper浅解

What is ZooKeeper?
ZooKeeper is a centralized service for maintaining configuration information, naming, providing distributed synchronization, and providing group services. All of these kinds of services are used in some form or another by distributed applications. Each time they are implemented there is a lot of work that goes into fixing the bugs and race conditions that are inevitable. Because of the difficulty of implementing these kinds of services, applications initially usually skimp on them, which make them brittle in the presence of change and difficult to manage. Even when done correctly, different implementations of these services lead to management complexity when the applications are deployed.

——官网原版解释

ZooKeeper是一个分布式的，开放源码的分布式应用程序协调服务，是Google的Chubby一个开源的实现，是Hadoop和Hbase的重要组件。它是一个为分布式应用提供一致性服务的软件，提供的功能包括：配置维护、域名服务、分布式同步、组服务等。
ZooKeeper的目标就是封装好复杂易出错的关键服务，将简单易用的接口和性能高效、功能稳定的系统提供给用户。
ZooKeeper包含一个简单的原语集，提供Java和C的接口。
ZooKeeper代码版本中，提供了分布式独享锁、选举、队列的接口，代码在zookeeper-3.4.3\src\recipes。其中分布锁和队列有Java和C两个版本，选举只有Java版本。

——百度百科

Zookeeper致力于提供一个高性能、高可用、严格顺序访问的分布式协调服务:
1.高性能。Zookeeper将所有数据存放在内存中，直接服务于客户端的非事务访问，尤其适用于读场景。
2.高可用。采用集群策略提供服务。集群中每台机器都会维护当前服务器状态，并保持通信。只要过半的机器可用，就能提供正常服务。
3.严格顺序访问。对于来自客户端的每个更新请求，ZooKeeper都会分配一个全局唯一的递增编号（ZXID，在ZooKeeper中对每一个事务请求，都会为其分配一个全局唯一的事务ID，使用ZXID表示，通常是一个64位的数字。每一个ZXID对应一次事务，从这些ZXID可以间接识别出ZooKeeper处理这些事务请求的全局顺序），这个编号反映了所有事务操作的先后顺序。
在分布式系统中，事务请求可能存在依赖关系，如变更C需要依赖变更A和变更B，这样就要求ZAB协议能够保证如果一个状态变更成功被处理了，那么其所有依赖的状态变更都应该已经提前被处理掉了。

Zeekeeper以集群的方式提供服务，集群包括多个节点，每个节点对应一台服务器，具有如下特性：

1.顺序一致性：同一客户端的请求，严格按照顺序发送到Zookeeper中。
2.原子性：集群中的服务器对于一个请求要么都处理，要么都不处理，不会出现部分处理部分不处理的情况。
3.单一性：集群中的服务器会互相同步数据，且数据结构等信息都是一致的。
4.可靠性：服务器的数据发生变化，马上存储起来，除非另一个请求使得数据发生了变更，否则一定是可靠的。
5.实时性：ZooKeeper保证数据的最终一致性。

分布式系统中，集群中的每一台服务器都有各自的角色，角色分三类：Leader/Follower/Observer。

Leader由众多服务器通过选举过程产生，是整个集群的核心，为客户端提供读和写服务：
1.事务请求（在ZooKeeper中，事务是指能够改变ZooKeeper服务器状态的请求，一般指创建节点、更新数据、删除节点以及创建会话操作。）的唯一调度者和处理者，保证集群事务处理的顺序性
2.集群内部各服务器的调度者

Follower为追随者，参与选举过程，并向leader转发事务请求，执行读操作：
1.参与Leader选举投票
2.处理客户端非事务请求 - 即读服务
3.转发事务请求给Leader服务器
4.参与事务请求Proposal的投票

Observer是ZooKeeper自3.3.0版本开始引入的一个全新的服务器角色，充当一个观察者角色，工作原理和Follower基本是一致的，和Follower唯一的区别是Observer不参与任何形式的投票：
1.处理客户端非事务请求 - 即读服务
2.转发事务请求给Leader服务器
3.不参与Leader选举投票
4.参与事务请求Proposal的投票

原子广播协议 - Zab。 zookeeper并没有采用传统的分布式一致性协议 - Paxos，而是参考了Paxos设计了一种更加轻量级的支持崩溃可恢复的原子广播协议-Zab（ZooKeeper Atomic Broadcast）。

1.领导选举 - Leader Election
当集群启动时，会选举一台节点为Leader，而其他节点为Follower，当Leader节点出现网络中断、崩溃退出与重启等异常情况，ZAB会进入恢复模式并选举产生新的Leader服务器，当集群中已有过半机器与该Leader服务器完成数据状态同步，退出恢复模式

2.原子广播 - Atomic Broadcast
当领导选举完成后，就进入原子广播阶段。此时集群中已存在一个Leader服务器在进行消息广播，当一台同样遵循ZAB协议的服务器启动后加入到集群中，新加的服务器会自动进入数据恢复阶段

节点：ZooKeeper内部拥有一个树状的内存模型，类似文件系统，只是在ZooKeeper中将这些目录与文件系统统称为ZNode，ZNode是ZooKeeper中数据的最小单元，每个ZNode上可以保存数据，还可以挂载子节点，因此构成了一个层次化的命名空间。

节点路径
ZooKeeper中使用斜杠（/）分割的路径表示ZNode路径，斜杠（/）表示根节点

watcher：在ZooKeeper中，引入Watcher机制来实现分布式数据的发布/订阅功能。ZooKeeper允许客户端向服务器注册一个Watcher监听，当服务器的一些指定事件触发了这个Watcher，那么就会向指定客户端发送一个事件通知来实现分布式的通知功能。

Watcher机制为以下三个过程：

1. 客户端注册Watcher
   在创建一个ZooKeeper客户端对象实例时，可以向构造方法中传入一个Watcher，这个Watcher将作为整个ZooKeeper会话期间的默认Watcher，一致保存在客户端，并向ZooKeeper服务器注册Watcher
   客户端并不会把真实的Watcher对象传递到服务器，仅仅只是在客户端请求中使用boolean类型属性进行标记，降低网络开销和服务器内存开销

2. 服务端处理Watcher
   服务端执行数据变更，当Watcher监听的对应数据节点的数据内容发生变更，如果找到对应的Watcher，会将其提取出来，同时从管理中将其删除（说明Watcher在服务端是一次性的，即触发一次就失效了），触发Watcher，向客户端发送通知

3. 客户端回调Watcher
   客户端获取通知，识别出事件类型，从相应的Watcher存储中去除对应的Watcher（说明客户端也是一次性的，即一旦触发就会失效）

特性：

1. 一致性：无论是客户端还是服务器，一旦一个Watcher被处罚，ZooKeeper都会将其从相应的存储中移除，因此开发人员在Watcher使用上要反复注册，这样可以有效减轻服务器压力
2. 客户端串行执行：客户端Watcher回调的过程是一个串行同步的过程，这保证了顺序
3. 轻量：客户端并不会把真实的Watcher对象传递到服务器，仅仅只是在客户端请求中使用boolean类型属性进行标记，降低网络开销和服务器内存开销

Session - 会话：客户端连接 - 客户端和服务器之间的一个TCP长连接

1. 心跳检测
   为了保证客户端会话的有效性，客户端会在会话超时时间范围内向服务器发送PING请求来保持会话的有效性，即心跳检测。
   服务器接收到客户端的这个心跳检测，就会重新激活对应的客户端会话

2. 会话清理
   服务器的超级检查线程会在指定时间点进行检查，整理出一些已经过期的会话后，就要开始进行会话清理了：
   （1）关闭会话，
   （2）清理相关的临时节点

3. 重连
   当客户端和服务器之间网络连接断开，客户端会自动进行反复的重连，直到最终成功连接上ZooKeeper集群中的一台机器

   （1）在会话超时时间内重新连接上，被视为重连成功
   （2）在会话超时时间外重新连接上，此时服务器已经进行了会话清理，但客户端不知道
   （3）会话已经失效，重新连接服务器会告诉客户端会话已失效，被视为非法会话

参考文献：
https://zookeeper.apache.org/
https://blog.csdn.net/lipinganq/article/details/81029499