zookeeper 理论

Zookeeper是什么？

引用官方的说法：“Zookeeper是一个高性能，分布式的，开源分布式应用协调服务。它提供了简单原始的功能，分布式应用可以基于它实现更高级 的服务，比如同步，配置管理，集群管理，名空间。它被设计为易于编程，使用文件系统目录树作为数据模型。服务端跑在java上，提供java和C的客户端 API”。

Zookeeper总体结构

Zookeeper服务自身组成一个集群(2n+1个服务允许n个失效)。Zookeeper服务有两个角色，一个是leader，负责写服务和数据同步，剩下的是follower，提供读服务，leader失效后会在follower中重新选举新的leader。

Zookeeper逻辑图如下，





客户端可以连接到每个server，每个server的数据完全相同。

每个follower都和leader有连接，接受leader的数据更新操作。

Server记录事务日志和快照到持久存储。

大多数server可用，整体服务就可用。

Zookeeper数据模型

Zookeeper表现为一个分层的文件系统目录树结构（不同于文件系统的是，节点可以有自己的数据，而文件系统中的目录节点只有子节点）。

数据模型结构图如下，





圆形节点可以含有子节点，多边形节点不能含有子节点。一个节点对应一个应用，节点存储的数据就是应用需要的配置信息。

Zookeeper 特点

顺序一致性：按照客户端发送请求的顺序更新数据。

原子性：更新要么成功，要么失败，不会出现部分更新。

单一性 ：无论客户端连接哪个server，都会看到同一个视图。

可靠性：一旦数据更新成功，将一直保持，直到新的更新。

及时性：客户端会在一个确定的时间内得到最新的数据。

Zookeeper运用场景

数据发布与订阅 （我的业务用到这个特性，后面会有详细介绍）

应用配置集中到节点上，应用启动时主动获取，并在节点上注册一个watcher，每次配置更新都会通知到应用。

名空间服务

分布式命名服务，创建一个节点后，节点的路径就是全局唯一的，可以作为全局名称使用。

分布式通知/协调

不同的系统都监听同一个节点，一旦有了更新，另一个系统能够收到通知。

分布式锁

Zookeeper能保证数据的强一致性，用户任何时候都可以相信集群中每个节点的数据都是相同的。一个用户创建一个节点作为锁，另一个用户检测该节点，如果存在，代表别的用户已经锁住，如果不存在，则可以创建一个节点，代表拥有一个锁。

集群管理

每个加入集群的机器都创建一个节点，写入自己的状态。监控父节点的用户会受到通知，进行相应的处理。离开时删除节点，监控父节点的用户同样会收到通知。

Zookeeper在我们业务逻辑上的运用

我们公司做极光推送，Push 业务平台有大量的逻辑服务器，按业务类型分组。逻辑服务的运行依赖于配置，并且配置会在线调整，需要一个集中的配置项管理中心。Zookeeper的发布 与订阅特性以及发送更新通知的机制很好的满足了我们的需求。Zookeeper的容灾特性也免去了我们相关的大量管理工作。

下面我主要和大家分享一下Zookeeper在我们内部服务中的应用。

a. 我们的逻辑服务器包含两类配置。

一种为Acl（访问控制列表），用户的消息消费后，按照列表中的条件走向下一个逻辑服务器。另一种只是单独的算法逻辑的外提，称为Agl（访问算法列表），但是其中某些判断条件会经常变化。这两类配置被收集到了配置管理中心（即Zookeeper）。

逻辑图如下，





用户编辑好策略配置信息（xml格式），通过客户端加载到Zookeeper。Zookeeper立即通知其下的逻辑服务器（BLx），逻辑服务器 下载最新的配置策略，并应用新的策略。新的策略有可能改变某一段id范围内用户的数据流向，或越过原来的逻辑服务器，或指向新加入的逻辑服务器。

b. 数据模型设计

同一类型的逻辑服务在Zookeeper上创建一个节点，共享相同的配置信息。
该节点下面为策略配置项，分为Acl和Agl两类，如下图：（以代理逻辑服务为例）





Acl1, Acl2, Acl3, Agl1, Agl2分别存有策略配置信息。变化后会通知监听Proxy节点的逻辑服务器，Proxy逻辑服务器下载最新策略，并应用该策略。新节点的加入和退出也会通知到Proxy逻辑服务器。

c. 业务处理流程如下图





逻辑服务监听自己类型节点（本例如前图Proxy节点）

编辑新策略,加载策略到Zookeeper（策略保存在Proxy/Acls/Acl[1..n]，或Proxy/Agls/Agl1[1..n]）

Zookeeper通知各逻辑节点

各逻辑节点下载新策略到本地，并应用新策略

 

 

1.3. Zookeeper基本知识
 
    在这一小结，我介绍关于ZooKeeper的一些基本理论知识，以便对ZooKeeper有一个基本感性的认识吧，由于学习的时间不长，有些的认识可能是比较片面的，之后如果有了更深层次的认识，会补充于之后的月总结中。
 
1.3.1. 层次化的名字空间
    ZooKeeper的整个名字空间的结构是层次化的，和一般的Linux文件系统结构非常相似，一颗很大的树。这也就是ZooKeeper的数据结构情况。名字空间的层次由斜杠/来进行分割，在名称空间里面的每一个结点的名字空间唯一由这个结点的路径来确定。

图3.1 ZooKeeper的层次化名字空间
    每一个节点拥有自身的一些信息，包括：数据、数据长度、创建时间、修改时间等等。从这样一类既含有数据，又作为路径表标示的节点的特点中，可以看出，ZooKeeper的节点既可以被看做是一个文件，又可以被看做是一个目录，它同时具有二者的特点。为了便于表达，今后我们将使用Znode来表示所讨论的ZooKeeper节点。
 
1.3.2. Znode
    Znode维护着数据、ACL（access control list，访问控制列表）、时间戳等交换版本号等数据结构，它通过对这些数据的管理来让缓存生效并且令协调更新。每当Znode中的数据更新后它所维护的版本号将增加，这非常类似于数据库中计数器时间戳的操作方式。
另外Znode还具有原子性操作的特点：命名空间中，每一个Znode的数据将被原子地读写。读操作将读取与Znode相关的所有数据，写操作将替换掉所有的数据。除此之外，每一个节点都有一个访问控制列表，这个访问控制列表规定了用户操作的权限。
    ZooKeeper中同样存在临时节点。这些节点与session同时存在，当session生命周期结束，这些临时节点也将被删除。临时节点在某些场合也发挥着非常重要的作用。
1.3.3. Watch机制
    Watch机制就和单词本身的意思一样，看。看什么？具体来讲就是某一个或者一些Znode的变化。官方给出的定义：一个Watch事件是一个一次性的触发器，当被设置了Watch的数据发生了改变的时候，则服务器将这个改变发送给设置了Watch的客户端，以便通知它们。
Watch机制主要有以下三个特点：
1 一次性的触发器（one-time trigger）
    当数据改变的时候，那么一个Watch事件会产生并且被发送到客户端中。但是客户端只会收到一次这样的通知，如果以后这个数据再次发生改变的时候，之前设置Watch的客户端将不会再次收到改变的通知，因为Watch机制规定了它是一个一次性的触发器。
2 发送给客户端
    这个表明了Watch的通知事件是从服务器发送给客户端的，是异步的，这就表明不同的客户端收到的Watch的时间可能不同，但是ZooKeeper有保证：当一个客户端在看到Watch事件之前是不会看到结点数据的变化的。例如：A=3，此时在上面设置了一次Watch，如果A突然变成4了，那么客户端会先收到Watch事件的通知，然后才会看到A=4。
3被设置Watch的数据
    这表明了一个结点可以变换的不同方式。一个Znode变化方式有两种，结点本身数据的变化以及结点孩子的变化。因此Watch也可以设置为这个Znode的结点数据，当然也可以设置为Znode结点孩子。
 
1.3.4. ACL访问控制列表
    这是另外一个和Linux操作系统非常相似的地方，ZooKeeper使用ACL来控制对旗下Znode结点们的访问。ACL的实现和Linux文件系统的访问权限十分类似：它通过设置权限为来表明是否允许对一个结点的相关内容的改变。
    但是与传统Linux机制不太相同，一个结点的数据没有类似“拥有者，组用户，其他用户”的概念，在ZooKeeper中，ACL通过设置ID以及与其关联的权限来完成访问控制的。ACL的权限组成语法是：
(scheme:expression, perms)
前者表明设置的ID，逗号后面表示的是ID相关的权限，例如：
 (ip:172.16.16.1, READ)
指明了IP地址为如上的用户的权限为只读。
 
以下列举以下ACL所具有的权限
CREATE：表明你可以创建一个Znode的子结点。
READ：你可以得到这个结点的数据以及列举该结点的子结点情况。
WRITE：设置一个结点的数据。
DELETE：可以删除一个结点
ADMIN：对一个结点设置权限。
 
1.4. ZooKeeper的部署以及简单使用
 
    要想使用ZooKeeper，首先就要把它部署在服务器上跑起来，就想Apache，Tomcat，FtpServer等服务器一样。ZooKeeper的部署方式主要有三种，单机模式、伪集群模式、集群模式。其实剩下的两种模式都是集群模式的特殊情况。