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)

猜你喜欢

转载自blog.csdn.net/itliwei/article/details/54381839
今日推荐