ZooKeeper Session分析

在ZooKeeper客户端与服务端成功完成建立连接后，就建立了一个会话。ZooKeeper会话在整个运行期间的生命周期中，会在不同的会话状态之间进行切换，这些状态一般可以分为CONNECTING、CONNECTED、RECONNECTING、RECONNECTED和CLOSE等。
Session 是ZooKeeper中最重要的概念之一。它包括4个基本属性：
sessionID:会话ID，唯一标识一个会话，每次客户端创建新会话的时候，ZooKeeper都会为其分配一个全局唯一的sessionID。TimeOut：会话超时时间。客户端在构造ZooKeeper实例的时候，会配置一个sessionTimeOut参数用于指定会话超时时间。ZooKeeper客户端向服务器发送这个超时时间后，服务器会根据自己的超时时间限制最终确定会话的超时时间。TickTime：下次会话超时时间点。为了便于ZooKeeper对会话实行“分桶策略”管理，同时也是为了高效低耗地实现的超时检测与清理，ZooKeeper会为每个会话标识一个下次会话超时时间。isClosing：该属性用于标记一个会话是否被关闭。通常当服务端检测到一个会话已经超时失效的时候，会将该会话的isClosing属性标记为“已关闭”，这样就能确保不再处理来自该会话的新请求了。

SessionTracker
SessionTracker是ZooKeeper服务端的会话管理器，负责会话的创建、管理和清理工作。每一个会话在SessionTracker内部都保留三份，具体如下。
sessionById：这是一个HashMap<Long,SessionImpl>类型的数据结构，用于根据sessionID来管理Session实体。sessionWithTimeout：这是一个ConcurrentHashMap<Long,Integer>类型的数据结构，用于根据sessionID来管理会话的超时时间。该数据结构和ZooKeeper内存数据库相连通，会被定期持久化到快照文件中。sessionSets：这是一个HashMap<Long,SessionSet>类型的数据结构，用于根据下次会话超时时间点来归档会话，便于进行会话管理和超时检查。在下文“分桶策略”会话管理的介绍中，我们还会对该数据结构进行详细讲解。

创建连接
服务端对于客户端的“会话创建”处理，大体可以分为四大步骤，分别是处理ConnectRequest请求、会话创建、处理器链路处理和会话响应。在ZooKeeper服务端首先将会由NIOServerCnxn来负责接收来自客户端的“会话创建”请求，并反序列化出ConnectRequest请求，然后根据ZooKeeper服务端的配置完成会话超时时间的协商。随后SessionTracker将会为该会话分配一个sessionID，并将其注册到sessionById和sessionWithTimeout中，同时进行会话激活。之后，该“会话请求”还会在ZooKeeper服务端的各个请求处理器之间进行顺序流转，最终完成会话的创建。
接下来分析一下session状态之间的转换：

Session从NOT_CONNECTED状态开始，并随着Zookeeper客户端初始化，转移到CONNECTING状态（在图1中的箭头1）。 正常情况下，客户端会与Zookeeper服务器连接成功，并且转移到CONNECTED状态（箭头2）。当客户端失去了与ZooKeeper服务器的连接或者不能听到服务器，它会转移回CONNECTING（箭头3），并且尝试寻找另一个ZooKeeper服务器。如果它能找到另一个服务器或者重新连接到之前的服务器，并确认了这个Session仍然有效，它会转移回CONNECTED状态。否则，它会定义这个Session失效，并转移到CLOSED（箭头4）。应用可以显示关闭Session。（箭头4和5）
如果客户端因为超时和服务器断开连接，它会保持在CONNECTING状态。如果这个断开是因为客户端和Zookeepe集群的网络中断，它将保持在CONNECTING状态直到它显示地关闭Session，或者网络中断恢复后客户端从Zookeeper服务器听到了Session超时消息。我们设计这样的行为是因为只有Zookeeper集群负责定义Session失效，而不是客户端。客户端不能定义Session失效，直到听到Zookeeper Session超时消息。然而，客户端可以选择主动关闭这个Session。
在创建Session时，需要设置Session Timeout这个重要参数。这是Zookeeper服务允许一个Session在定义它失效之前的时间。如果服务在时间t内不能看到与一个Session关联的消息，它将定义这个Session失效。如果客户端在1/3 t时间内没有听到任何从服务器过来的消息，它将发送一个心跳消息给服务器。在(2/3)t时间， Zookeeper客户端开始寻找另一个Zookeeper服务器，并且它有另外的(1/3)t的时间寻找。
客户端将连接哪一个服务器
在Quorum模式，一个客户端拥有多个服务器可以连接。然而在Standalone模式，它必须尝试重新有效地连接到那个唯一的服务器。在Quorum模式，应该会传一个服务器列表到客户端，客户端从中选择一个连接。
当尝试连接另一个服务器时，很重要的一点是这个服务器的ZooKeeper状态至少要和客户端已经观察到的最近ZooKeeper状态是一样新的。客户端不能连接到一个这样的服务器。它没有看到客户端可能已经看到的更新。Zookeeper通过在服务中排序更新操作来决定新鲜程度(Freshness)。每一个对Zookeeper布局状态的改动操作相对于所有其它执行的更新操作都是全序的，所以如果一个客户端已经在位置i观察到一个更新，它不能连接一个仅看到i' < i的服务器。在ZooKeeper的实现中，系统分配给每个更新操作一个事务ID来建立这个顺序。

更多精彩内容，欢迎关注微信公众号：Java小笔记（ijavanote）