背景

继续前面的zookeeper学习的专题，这次主要是结合项目中遇到的一些问题，进一步学习了下zookeeper的一些内部机制。

针对以下几个问题：

1. zk是否可以保证watcher事件不丢失？

2. zk的EPHEMERAL节点的自动过期时间？

3. zk的如何保证节点数据不丢失？

如果你已经非常清楚这以上的几个问题，看官们可以不用往下看了。

persit机制

zookeeper中的persit机制主要是通过本地disk进行持久化，在本地disk上会有个memory数据对象保持同步。

持久化实现：

ZKDatabase

  • DataTree (内存树)

  • FileTxnSnapLog (disk持久化)

  • committedLog (FileTxnSnapLog的一份内存数据cache，默认存储500条变更记录)

DataTree(内存树)

zookeeper本身的数据结构就是一个树结构

数据模型（DataTree）:

  • DataNode (1:n)

  • data WatchManager (1:1，处理node节点的CRUD的变更事件，发送Watcher事件)

  • child WatchManager (1:1,  处理node子节点的变更事件，发送Watcher事件)

  • sessions (ephemerals)

DataNode模型：

  • parent

  • data byte[]

  • acl(安全)

  • stat(审计信息)

  • children

整个实现相对比较简单，就是查找一个树节点后进行响应的操作

FileTxnSnapLog (disk持久化)

持久化数据分两类：

  • TxnLog (类似于mysql/oracle的binlog/redolog)

  • SnapShot (DataTree的数据镜像)

刚开始最容易搞不清楚就是Txnlog和SnapShot的区别，SnapShot主要是定期对DataTree的数据做一个本地备份，TxnLog只是一些历史的版本变更日志(每次由写事件变化，就会写入到该日志中)。
下面看一下，zookeeper在新节点启动后，是否如何保证数据一致：

  1. 首先节点启动后，尝试读取本地的SnapShot log数据(zkDb.loadDataBase())，反序列化为DataTree对象，并获取last zxid。

  2. follower启动后会向leader发送自己的last zxid

  3. leader收到zxid后，对比自己当前的ZKDatabase中的last zxid

    如果当前follower的zxid在内存committedLog中，直接将内存中的committedLog提取出来进行发送，否则将当前的DataTree直接发送给follower.(不再是发送变更记录)

  4. 数据同步完成后，follower会开始接收request请求

一致性机制

整个zk集群在处理数据变更过程中，会是先append变更信息到Txnlog中(此时会触发take snap操作)，最后在FinalRequestProcessor中更新内存中的DataTree信息。

触发take snap的条件：

Java代码  

  1. if (logCount > (snapCount / 2 + randRoll)) {  

  2. randRoll = r.nextInt(snapCount/2);  

snapCount可以通过jvm参数zookeeper.snapCount指定，默认为100000。 这里zookeeper很巧妙的加两个随机处理，避免zk机器在同一时间点进行take snap处理，影响性能。

session机制

zookeeper会为每个client分配一个session，类似于web服务器一样。针对session可以有保存一些关联数据，zookeeper里针对session的一些关联数据主要就是EPHEMERAL节点。

EPHEMERAL的翻译为短命的，技术上理解就是session关闭后，其节点即消失，和session保持相同的生命周期。

创建EPHEMERAL节点：

Java代码  

  1. zookeeper.create(path, data, ZooDefs.Ids.OPEN_ACL_UNSAFE, CreateMode.EPHEMERAL);  

我们能用EPHEMERAL节点做啥?

  1. 分布式集群是否存活监控. (每个节点启动后，注册一个EPHEMERAL节点到zookeeper中，注册一个Watcher获取EPHEMERAL节点的存在情况，消失即可代表集群节点dead)

  2. 分布式lock (每个锁竞争者，排队时都在zookeeper中注册一个EPHEMERAL节点，排队过程中有节点dead了，zookeeper可以自动将其剔除队列，避免出现deadlock)

  3. 替代web服务器的session，实现一个集中式session, session数据中的setAttribute都创建为EPHEMERAL节点，session关闭后即可自动删除，不会造成java中的"内存泄漏"

不扯远，下面看一下zookeeper中是如何处理session的管理？ 因为用上了zookeeper，必然要考虑分布式常见的问题
比如：

  1. zookeeper server挂了，对应的session是否会丢失?

  2. zookeeper client发生了failover后(出现了Connection Loss异常)，对应的session是否会丢失?

解答：

  1. 在服务端，zookeeper中session的存储是有进行持久化的, 具体可见perist机制的描述。 一个新节点启动后，会从leader中同步对应的session数据

  2. 在客户端，zookeeper在每次出现failover后(出现了Connection Loss异常)，会重新带上sessionId,sessionPasswd发起一次链接请求。接收到该请求的server，会返回内存中的session信息

所以，session是有可靠性保证的。

session expired机制

zookeeper中session expired机制和node数据一致性的保证原理类似，对应的follower都是受控于leader。

  1. follower接收到客户端链接请求，就会向leader发送一次createSession的操作请求，leader收到后进行广播通知给所有的follower/observer节点createSession

  2. leader会通过内存版的(SessionTrackerImpl)，定期扫描过期的session，发送一次closeSession的请求给所有的客户端

  3. 在2发送过程中，如果有follower接收到过期session的请求，会提交给leader进行仲裁，leader会直接返回session expired。

session expired几个参数:

  1. 服务端: minSessionTimeout (默认值为：tickTime * 2) , maxSessionTimeout (默认值为 : tickTime * 20) , ticktime的默认值为3000ms。所以session范围为6s ~ 60s

  2. 客户端： sessionTimeout， 无默认值，创建实例时必填。

一个误区： 很多人会按照hadoop文档中的建议，创建zookeeper客户端时设置了
sessionTimeout为90s，而没有改变server端的配置，默认是不会生效的。
原因： 客户端的zookeeper实例在创建连接时，将sessionTimeout参数发送给了服务端，服务端会根据对应的minSessionTimeout/maxSessionTimeout的设置，强制修改sessionTimeout参数，也就是修改为6s~60s返回的参数。所以服务端不一定会以客户端的sessionTImeout做为session expire管理的时间。
Java代码  

  1. <span style="font-weight: normal;">int minSessionTimeout = zk.getMinSessionTimeout();  

  2. if (sessionTimeout < minSessionTimeout) {  

  3.            sessionTimeout = minSessionTimeout;  

  4.        }  

  5. int maxSessionTimeout = zk.getMaxSessionTimeout();  

  6. if (sessionTimeout > maxSessionTimeout) {  

  7.            sessionTimeout = maxSessionTimeout;  

  8.        }</span>  

Watcher机制

watcher是zookeeper实现分布式lock一个很重要的feature，在写分布式lock时一定要对其有所了解。

就会冒出如下问题：

  1. 什么情况下，会触发什么类型的watcher?

  2. watcher信息出现failover是否会丢失?

  3. watcher信息出现session expired是否会丢失？

针对第一个问题，需要在使用中详细阅读下对应Zookeeper类中方法的javadoc，注意几个点：

  • exists方法： 设置watcher时，如果对应服务端已经不存在node时，watcher是不会留在服务端，下次不会被触发。针对这种情况需要判断返回的stat == null来进行处理

  • getChildren方法： 和exist一样，需要处理节点不存在时watcher不会被记录。 还有一个点，当前的父node发生delete变化时，也可以得到触发

  • getData方法： 和exist一样，需要处理节点不存在时watcher不会被记录

要了解watcher是否会丢失，必须要清楚zookeeper整套watcher机制的实现：

  • Watcher是一个本地jvm的callback，在和服务端交互过程中是不会进行传递的。只是会将是否有watcher的boolean变量传递给server端

  • 在服务端，在FinalRequestProcessor处理对应的node操作时，会根据客户端传递的watcher变量，添加到对应的zkDataBase中进行持久化存储，同时将自己NIOServerCnxn做为一个Watcher callback，监听服务端事件变化

  • leader通过投票通过了某次node变化请求后，通知给对应的follower，follower根据自己内存中的zkDataBase信息，发送notification信息给zookeeper 客户端

  • zookeeper客户端接收到notification信息后，找到对应变化path的watcher列表，挨个进行触发回调。

整个流程图：
9dfc12f0-a7f7-312d-ae11-0b2c2bfdb934.jpg
可能存在的问题：
1. client向连接的server提交了watcher事件后，对应的server还未来得及提交给leader就直接出现了jvm crash，这时对应的watcher事件会丢失。(理论上正常关闭zookeeper server，不会存在该问题，需要客户端进行重试处理)
2. client在发生一次failover时，可以自动对新的server的notification使用watcher set，可以通过设置jvm变量：zookeeper.disableAutoWatchReset进行，默认为false。如果为true，则不进行自动使用的行为)
3. client出现session expired时，需要重新创建一个zookeeper client实例，此时对应的watcher set也会丢失，需要自己编码做一些额外的处理

zookeeper异常处理

官方文档：

主要处理两个系统异常：

  • KeeperException.ConnectionLossException (client与其中的一台server socket链接出现异常)

  • KeeperException.SessionExpiredException (client的session超过sessionTimeout为进行任何操作)

ConnectionLossException可以通过重试进行处理，在ClientCnxn会根据你初始化ZooKeeper时传递的服务列表，自动尝试下一个server节点
SessionExpiredException不能通过重试进行解决，需要应用重新new Zookeeper()，创建一个新的客户端，包括重新初始化对应的watcher，EPHEMERAL节点等。

最后

思路可能写的有点乱，文中所有的内容均通过阅读源码所得，如有不对的地方，尽情拍砖。