zookeeper理论

数据模型znode

        zk数据存储结构与标准的Unix文件系统非常相似，都是在根节点下挂很多子节点。zk中没有引入传统文件系统中目录与文件的概念，而是使用了称为znode的数据节点概念。znode是zk中数据的最小单元，每个znode上都可以保存数据，同时还可以挂载子节点，形成一个树形化命名空间。

1 节点类型

• 持久节点：默认创建节类型，一经创建永久存在，除非主动删除；
• 持久顺序节点：在一个主节点下可以对其子节点进行顺序创建管理；例如，根节点下A、A'、A''，节点除了名字外，会创建一个十位数字顺序编号，A[0000000000]、A'[0000000001]，A''[0000000002];
• 临时节点：临时节点的生命周期与客户端的会话(sessionID)绑定在一起,临时节点不能有子节点，即临时节点只能是叶子节点;
• 临时顺序节点

2 节点状态

• cZxid：Created Zxid，表示当前znode被创建时的事务ID
• ctime：Created Time，表示当前znode被创建的时间
• mZxid：Modified Zxid，表示当前znode最后一次被修改时的事务ID
• mtime：Modified Time，表示当前znode最后一次被修改时的时间
• pZxid：表示当前znode的子节点列表最后一次被修改时的事务ID。注意，只能是其子节点列表变更了才会引起pZxid的变更，子节点内容的修改不会影响pZxid。
• cversion：Children Version，表示子节点的版本号。该版本号用于充当乐观锁。
• dataVersion：表示当前znode数据的版本号。该版本号用于充当乐观锁。
• aclVersion：表示当前znode的权限ACL的版本号。该版本号用于充当乐观锁。
• ephemeralOwner：若当前znode是持久节点，则其值为0；若为临时节点，则其值为创建该节点的会话的SessionID。当会话消失后，会根据SessionID来查找与该会话相关的临时节点进行删除。
• dataLength：当前znode中存放的数据的长度。
• numChildren：当前znode所包含的子节点的个数。

会话

        会话是zk中最重要的概念之一，客户端与服务端之间的任何交互操作都与会话相关；ZooKeeper客户端启动时，首先会与zk服务器建立一个TCP长连接，连接一旦建立，客户端会话的生命周期也就开始了。

1 会话状态

常见的会话状态有三种：

• CONNECTING：连接中。客户端要创建连接，其首先会在客户端创建一个zk对象，代表服务器；其会采用轮询的方式对服务器列表逐个尝试连接，直到连接成功；不过，为了对Server进行负载均衡，其会首先对服务器列表进行打散操作，然后再轮询。
• CONNECTED：已经连接，会生产一个sessionID；
• CLOSED：连接已经关闭，关闭zk对象，清除sessionID；

2 会话连接事件

        客户端与服务端的长连接失效后，客户端将进行重连。在重连过程中客户端会产生三种会话连接事件：

• CONNECTION_LOSS：连接丢失。因为网络抖动等原因导致连接中断，在客户端会引发连接丢失事件。该事件会触发客户端逐个尝试重新连接服务器，直到连接成功，或超时。
• SESSION_MOVED：会话转移。当连接丢失后，在SessionTimeout内重连成功，则SessionId是不变的。若两次连接上的Server不是同一个，则会引发会话转移事件。该事件会引发客户端更新本地zk对象中的相关信息。
• SESSION_EXPIRED：会话失效。若客户端在SessionTimeout内没有连接成功，则服务器会将该会话进行清除，并向Client发送通知。但在Client收到通过之前，又连接上了Server，此时的这个会话是失效的，会引发会话失效事件。该事件会触发客户端重新生成新的SesssionId重新连接Server。

3 会话连接超时管理--分桶策略(服务端连接超时管理)

        无论是会话状态还是会话连接事件，都与会话超时有着紧密的联系。zk中对于会话的超时管理，采用了一种特殊的方式——分桶策略。

基本概念

        分桶策略是指，将超时时间相近的会话放到同一个桶中来进行管理，以减少管理的复杂度。在检查超时时，只需要检查桶中剩下的会话即可，因为没有超时的会话(连接成功)已经被移出了桶，而桶中存在的会话就是超时的会话。zk对于会话的超时管理并非是精确的管理，即并非是一超时马上就执行相关的超时操作。

分桶依据

分桶的计算依据为：

ExpirationTime= CurrentTime + SessionTimeout
BucketTime = (ExpirationTime/ExpirationInterval + 1) * ExpirationInterval

从以上公式可知，一个桶的大小为ExpirationInterval时间。只要ExpirationTime落入到同一个桶中，系统就会对其中的会话超时进行统一管理。

ACL

1 ACL简介

        ACL全称为Access Control List（访问控制列表），是一种细粒度的权限管理策略，可以针对任意用户与组进行细粒度的权限控制。zk利用ACL控制znode节点的访问权限，如节点数据读写、节点创建、节点删除、读取子节点列表、设置节点权限等。
        UGO(windows，linux2.6版本以下)，粗粒度权限管理，只能管理到group（组），针对单用户无法单独管理。

2 zk的ACL维度

        Unix/Linux系统的ACL分为两个维度：组与权限，且目录的子目录或文件能够继承父目录的ACL的。而Zookeeper的ACL分为三个维度：授权策略scheme、授权对象id、用户权限permission，子znode不会继承父znode的权限。

A、授权策略scheme
授权策略用于确定权限验证过程中使用的检验策略（简单地说就是，通过什么来验证权限，即一个用户要访问某个znode，如何验证其身份），在zk中最常用的有四种策略。

• IP：根据IP进行验证。
• digest：根据用户名与密码进行验证。
• world：对所有用户不做任何验证。
• super：超级用户对任意节点具有任意操作权限。

B、授权对象id
授权对象指的是权限赋予的用户。不同的授权策略具有不同类型的授权对象。下面是各个授权模式对应的授权对象id。

• ip：将权限授予指定的ip
• digest：将权限授予具有指定用户名与密码的用户。
• world：将权限授予一个用户anyone
• Super：将权限授予具有指定用户名与密码的用户。

C、权限Permission
权限指的是通过验证的用户可以对znode执行的操作。共有五种权限，不过zk支持自定义权限。

• c：Create，允许授权对象在当前节点下创建子节点
• d：Delete，允许授权对象删除当前节点
• r：Read，允许授权对象读取当前节点的数据内容及子节点列表
• w：Write，允许授权对象修改当前节点数据内容及子节点列表（可以为当前节点增/删除子节点）
• a：Acl，允许授权对象对当前节点进行ACL设置

Watcher机制

zk通过Watcher机制实现了发布/订阅模式。

1 watcher工作原理

2 watcher事件-对于同一个事件类型，在不同的通知状态中代表的含义是不同的。

3 watcher特性:zk的watcher机制具有以下几个特性。

• 一次性：watcher机制不适合监听变化非常频繁的场景。
• 串行性：只有当当前的watcher回调执行完毕了，才会向server注册新的watcher（注意，是对同一个节点相同事件类型的监听）。
• 轻量级：Client向Server发送的watcher不是一个完整的，而是简易版的。另外，回调逻辑不是Server端的，而是Client的。