Zookeeper学习笔记3-Session、Watches和ACLs权限

5. Session

5.1 状态

CONNECTING、CONNECTED、RECONNECTING、RECONNECTED、CLOSE等。一旦客户端开始创建Zookeeper对象，那么客户端状态就会变成CONNECTING状态，同时客户端开始尝试连接服务端，连接成功后，客户端状态变为CONNECTED，通常情况下，由于断网或其他原因，客户端与服务端之间会出现断开情况，一旦碰到这种情况，Zookeeper客户端会自动进行重连服务，同时客户端状态再次变成CONNCTING，直到重新连上服务端后，状态又变为CONNECTED，在通常情况下，客户端的状态总是介于CONNECTING和CONNECTED之间。但是，如果出现诸如会话超时、权限检查或是客户端主动退出程序等情况，客户端的状态就会直接变更为CLOSE状态。

5.2 创建

Session是Zookeeper中的会话实体，代表了一个客户端会话，其包含了如下四个属性
1） sessionID。会话ID，唯一标识一个会话，每次客户端创建新的会话时，Zookeeper都会为其分配一个全局唯一的sessionID。
2） TimeOut。会话超时时间，客户端在构造Zookeeper实例时，会配置sessionTimeout参数用于指定会话的超时时间，Zookeeper客户端向服务端发送这个超时时间后，服务端会根据自己的超时时间限制最终确定会话的超时时间。
3） TickTime。下次会话超时时间点，为了便于Zookeeper对会话实行"分桶策略"管理，同时为了高效低耗地实现会话的超时检查与清理，Zookeeper会为每个会话标记一个下次会话超时时间点，其值大致等于当前时间加上TimeOut。
4） isClosing。标记一个会话是否已经被关闭，当服务端检测到会话已经超时失效时，会将该会话的isClosing标记为"已关闭"，这样就能确保不再处理来自该会话的心情求了。
Zookeeper为了保证请求会话的全局唯一性，在SessionTracker初始化时，调用initializeNextSession方法生成一个sessionID，之后在Zookeeper运行过程中，会在该sessionID的基础上为每个会话进行分配，初始化算法如下
使用文件机器所在id的前8位，再加上当前时间毫秒数的后56位。

5.3 管理

Zookeeper的会话管理主要是通过SessionTracker来负责，其采用了分桶策略（将类似的会话放在同一区块中进行管理）进行管理。

计算公式：ExpirationTime = ((CurrentTime + SessionTimeOut) / ExpirationInterval + 1) * ExpirationInterval
其中ExpirationInterval默认是tickTime的值。
1） 当客户端发送读写时，或者sessionTimeout/3时间内客户端没有反应，服务器主动发出ping。
2） 得到回应后，计算新的ExpirationTime_New值。
3） 获取上次的ExpirationTime_Old值。
4） 会话迁移，将会话从老的块区取出，放入新的块区。
5） SessionTracker有一个清理的线程，按照时间线逐步处理过期会话。

6. Watches

6.1 Watches

Zookeeper有2种watch，分别是data watches和child watches。命令getData() 和 exists() 设置会触发data watches，getChildren()设置会触发child watches。

6.2 特性

（一次性触发）One-time trigger
当设置监视的数据发生改变时，该监视事件会被发送到客户端，例如，如果客户端调用了 getData(“/znode1”, true) 并且稍后 /znode1 节点上的数据发生了改变或者被删除了，客户端将会获取到 /znode1 发生变化的监视事件，而如果 /znode1 再一次发生了变化，除非客户端再次对 /znode1 设置监视，否则客户端不会收到事件通知。

（发送至客户端）Sent to the client
Zookeeper 客户端和服务端是通过 socket 进行通信的，由于网络存在故障，所以监视事件很有可能不会成功地到达客户端，监视事件是异步发送至监视者的，Zookeeper 本身提供了保序性(ordering guarantee)：即客户端只有首先看到了监视事件后，才会感知到它所设置监视的 znode 发生了变化(a client will never see a change for which it has set a watch until it first sees the watch event). 网络延迟或者其他因素可能导致不同的客户端在不同的时刻感知某一监视事件，但是不同的客户端所看到的一切具有一致的顺序。

（被设置 watch 的数据）The data for which the watch was set
这意味着 znode 节点本身具有不同的改变方式。你也可以想象 Zookeeper 维护了两条监视链表：数据监视和子节点监视(data watches and child watches) getData() and exists() 设置数据监视，getChildren() 设置子节点监视。 或者，你也可以想象 Zookeeper 设置的不同监视返回不同的数据，getData() 和 exists() 返回 znode 节点的相关信息，而 getChildren() 返回子节点列表。因此， setData() 会触发设置在某一节点上所设置的数据监视(假定数据设置成功)，而一次成功的 create() 操作则会出发当前节点上所设置的数据监视以及父节点的子节点监视。一次成功的 delete() 操作将会触发当前节点的数据监视和子节点监视事件，同时也会触发该节点父节点的child watch。

6.3 zookeeper对于watches的保证

1） watch对于其他事件，其他watch，和异步回复都的是有序的。zookeeper库会保证所有事情按顺序被分发。
2） 客户会先收到watch事件，然后才会看到新的数据。
3） 来自zookeeper watch事件的顺序与zookeeper服务看到的更新一致

6.4 注意事项

1） Watch 是一次性的，如果 watch 事件发生了，还想 watch 需要再设置新的watch
2） 因为 watch 的一次性，再次注册 watch 的网络延迟，所以 znode 每次变更不可能都 watch 到
3） 一个 watch 对象或者函数/上下文对(pair)，只会触发一次。比如，如果相同的 watch 对象注册了 exist 和 getData 调用在相同文件，并且文件已经被删除，watch 对象只会在文件被删除触发一次
4） 当你与一个服务断开（比如zk服务宕机），你将不会获得任何 watch，直到连接重连。因此，session 事件将会发送给所有 watch 处理器。使用 session 事件进入一个安全模式：当断开连接的时候将不会收到任何事件，因此您的进程应该以该模式保守运行

7. ACLs权限

7.1 权限

1） CREATE©: 创建权限，可以在在当前node下创建child node
2） DELETE(d): 删除权限，可以删除当前的node
3） READ®: 读权限，可以获取当前node的数据，可以list当前node所有的child nodes
4） WRITE(w): 写权限，可以向当前node写数据
5） ADMIN(a): 管理权限，可以设置当前node的permission

7.2 维度

从三个维度来理解：一是scheme; 二是user（可以用户名或者ip）; 三是permission（即上面的权限），通常表示为scheme🆔permissions。

scheme

scheme: scheme对应于采用哪种方案来进行权限管理，zookeeper实现了一个pluggable的ACL方案，可以通过扩展scheme，来扩展ACL的机制。zookeeper-3.4.4缺省支持下面几种scheme:
world: 它下面只有一个id, 叫anyone, world:anyone代表任何人，zookeeper中对所有人有权限的结点就是属于world:anyone的
auth: 它不需要id, 只要是通过authentication的user都有权限（zookeeper支持通过kerberos来进行authencation, 也支持username/password形式的authentication)
digest: 它对应的id为username:BASE64(SHA1(password))，它需要先通过username:password形式的authentication
ip: 它对应的id为客户机的IP地址，设置的时候可以设置一个ip段，比如ip:192.168.1.0/16, 表示匹配前16个bit的IP段
super: 在这种scheme情况下，对应的id拥有超级权限，可以做任何事情(cdrwa)
sasl: sasl的对应的id，是一个通过sasl authentication用户的id，zookeeper-3.4.4中的sasl authentication是通过kerberos来实现的，也就是说用户只有通过了kerberos认证，才能访问它有权限的node。

id

id与scheme是紧密相关的，具体的情况在上面介绍scheme的过程都已介绍，这里不再赘述。

permission

权限cdrwa。

7.3 认证方式

方式一：（推荐）

1）增加一个认证用户
addauth digest 用户名:密码明文
eg. addauth digest user1:password1
2）通过setAcl设置权限
setAcl /path auth:用户名:密码明文:权限
eg. setAcl /test auth:user1:password1:cdrwa
3）查看Acl设置
getAcl /path
4）通过ip设置权限
setAcl /path ip:ip地址，使用/可以分段。
eg. setAcl /test ip: 192.168.1.0/16

方式二：

setAcl /path digest:用户名:密码密文:权限
注：这里的加密规则是SHA1加密，然后base64编码