客户端连接zk,有zk分配一个全局唯一的sessionId,客户端需要配置超时时间timeOut并传到zk,zk会据此计算会话下一次超时的时间点,zk根据这个时间点按照分桶策略进行分开存放,zk会给session设置一个isClosing属性、如果检测到超时会将该属性标记为关闭。
会话状态:CONNECTING、CONNECTED、RECONNECTING、RECONNECTED、CLOSE
SessionTracker:zk中的会话管理器,负责会话的创建、管理和清理
- sessionsWithTimeout:一个ConcurrentHashMap,用来管理会话的超时时间
- sessionsById:HashMap,维护sessionId到session的映射
- sessionsSets:HashMap,会话超时后进行归档,便于恢复和管理
ExpiractionTime = CurrentTime + SessionTimeout
SessionTracker根据ExpiractionTime将session进行分桶管理,同时按照一定的时间间隔进行定期检查,
同时客户端读写请求都可以将session的超时时间重置,SessionTracker会将session进行分桶迁移,如果没有读写请求,客户需要发送ping心跳链接,否则session超时会被清除
会话清理:
- 标记isClosing为关闭,此时该会话有新的请求也无法处理
- 发起会话关闭请求,同步到整个集群,使用提交的方式
- 收集需要清理的临时节点,先获取内存数据库中会话对应的临时节点集合,如果此时有删除节点的请求到达,将请求对应的节点路径从集合中移除,避免重复删除,如果有创建节点请求到达、则将请求中的路径添加到集合中
- 添加删除事务变更,将节点删除事务添加到outstandingChanges中,触发watch
- 删除临时节点
- 移除会话
- 关闭连接
连接断开后客户端可以重连zk,如果该session未过期,session重新变为CONNECTED
如果时间超过sessinTimeout,服务器则会进行会话的清理工作,如果此时ZK客户端才恢复连接,则会收到State为Expired的WatchedEvent,并断开与服务器的连接。
重连:断开后更换服务器链接,RECONNECTING状态,会将会话迁移到新连接的服务器上
当一个客户端发一个心跳请求个服务端,但是网络延时,导致服务端没有收到,过一会后,客户端连接上了另一个新的服务端,在这之后,之前的心跳被旧的服务端收到了,这时候旧的服务端会被提醒,当前session已经被转移了,然后旧的服务端会关闭这个连接。客户端一般不会感知到这个异常,因为旧连接一般都会被关闭。但是还有一个特殊情况,两个客户端同时使用保存这的session id+密码来重新连接服务端,第一个连接成功,紧着第二个又连接成功,这会导致第一个连接被关闭,然后就是这两个客户端无限重连了
暂无评论内容