zookeeper如何管理客户端与服务端之间的链接？（zookeeper sessions）

最新推荐文章于 2024-09-07 02:16:01 发布

不腾

最新推荐文章于 2024-09-07 02:16:01 发布

阅读量1.3k

点赞数 26

分类专栏： zookeeper系列文章标签： zookeeper 分布式

本文链接：https://blog.csdn.net/lamfang/article/details/109010744

版权

zookeeper系列专栏收录该内容

13 篇文章 10 订阅

订阅专栏

zookeeper客户端与服务端之间的链接用zookeeper session表示。

zookeeper session有三个状态：

CONNECTING, ASSOCIATING, CONNECTED, CONNECTEDREADONLY, CLOSED, AUTH_FAILED,

NOT_CONNECTED（start时的状态）

1、CONNECTING 。

表明客户端正在与服务端建立连接。当客户端的句柄正在建立时，在java中，也就是ZkClient对象在创建后，到与服务端建立起真正链接的过程中，zookeeper的session状态是connecting。

2、CONNECTED

表明客户端与服务端已经建立链接。

3、CLOSE

表明客户端与服务端之间的链接已经关闭。

当以下四种事件发生时，session的状态就会发生改变。

1、当session处于CONNECTING状态，客户端请求被加入到连接请求队列CONNECTING requests queue，执行成功后，会触发CONNECTED EVENT，session状态为CONNECTED。

2、当session处于CONNECTING状态，但是客户端与服务端尝试连接的过程中权限校验不通过，触发AUTH_FAILED event，客户端请求返回AUTH_FAILED，连接建立结束。

3、当连接已经建立，session处于CONNECTED状态时，服务端突然出现故障或其他因素导致链接失效，触发DISCONNECTED event，返回CONNECT_LOSS。客户端重新将请求加入到连接请求队列CONNECTING requests queue，session状态重新变为CONNECTING。此时客户端有两个选择：

重新向zookeeper集群中的其他服务器发起连接，成功则触发CONNECTED event，session状态变为CONNECTED，不断尝试直到超时则会造成session timeout，触发SESSION_EXPIRED event，请求返回SESSION_EXPIRED ，同时session状态修改为CLOSE。

或者，客户端直接请求关闭连接，返回CONNECTION LOSS，session状态变为CLOSE。

整个过程如下图所示：

State transitions

zookeeper 客户端与服务端建立链接时有三个参数，一个是地址串，一个是超时时间timeout，一个是监听器。

地址参数表明客户端向哪个zookeeper server发起连接请求。

当你使用多个zookeeper server地址时，多个地址用逗号隔开，比如“127.0.0.1:3000,127.0.0.1:3001,127.0.0.1:3002”，zookeeper客户端会随机连接到某个server上，如果连接失败，客户端会不断连接到其他server地址上，直到成功。

 zkClient = new ZooKeeper("127.0.0.1:3000,127.0.0.1:3001,127.0.0.1:3002", 2000,null);

当链接建立时，客户端所处的路径便是zookeeper server的根节点"/“。我们知道zookeeper没有相对路径的说法，客户端访问的所有节点都需要是绝对路径。那假设我们的配置信息分开发环境env和生产环境prod。开发环境的配置信息放在/env节点下，生产环境的配置放在/prod下。我们在开发时访问zookeeper的任何节点都需要加上前缀/env或者/prod。这样太麻烦了也容易出错。

于是zookeeper提供了一种方法，让我们可以在链接建立之后，访问的所有节点都相对于某个路径。

我们在连接地址串后面加上地址，比如：

        zkClient = new ZooKeeper("127.0.0.1:3000,127.0.0.1:3001,127.0.0.1:3002/env", 2000,null);

那么当链接建立后，我们访问getData("/a")，实际上访问的是"/env/a”节点。

zookeeper session建立后，服务端会返回一个64位的session id 与针对这个session id设立的密码给客户端。当客户端所连接的这个服务端出现故障导致DISCONNECT event发生后，客户端将会尝试和其他服务端建立链接。客户端会将之前保存的session id与密码发送给新连接的服务端，以保证会话数据和原来一样。

timeout超时时间

session 的超时时间由zookeeper集群自己管理。超时时间是指当session建立后，客户端多长时间没有与服务端进行交互（包括维持连接的心跳也没有）时，集群认为session失效。zookeeper集群会删除这个会话，并且删除这个会话建立的所有临时节点，同时通知所有监听这些临时节点的zookeeper客户端，当然，对于这个这个被删除会话的客户端而言，在它重新连接上zookeeper集群之前它是收不到这个通知的，毕竟如果这个客户端是正常的，那么它就会和zookeeper集群保持心跳以维持会话。会话超时说明这个客户端断开了链接，哪怕zookeeper集群的功能再强大，它也通知不到这个已经失去联系的客户端。

timeout时间最小是ticktime的两倍时间，最长是20倍。当客户端设置timeout值小于两倍ticktime时，zookeeper server实际返回的是ticktime的两倍时间。

当客户端所连接的server下线时，只要在timeout时间内，客户端能自动重连上zookeeper集群中的其他server，那么会话就能够保持。

zookeeper推荐由zookeeper客户端去负责重连的事情，直到请求返回session expired，此时我们再在自己的程序里去建立一个新的会话。而不是监听到所连接的server下线就立马去建立新的session，那样容易会发生“羊群效应”，也就是当server下线后，所有之前与这个服务端连接的客户端同时申请建立新的会话，会对zookeeper集群造成很大的压力。

SessionMovedException

这是一个内部异常，一般而言来说，客户端不会见到这个异常。当客户端向server A发起请求时，由于网络原因，在请求到达server时客户端就因为长时间没有收到响应而认为A已经下线，进而向server B建立会话。此时请求到达server A，A检测到会话已经转移，就会关闭与这个客户端的tcp链接。这一切都是由zookeeper在内部完成的，正常情况下客户端不会看到这个错误。

当有两个客户端在重建同一个链接时，其中一个客户端建立起的链接会因为另一个客户端建立起同样的链接而失效，从而重新建立链接。不断反复建立，失效，建立，失效，陷入一个死循环中。

在zookeeper3.5.0后加入一个local session概念。

zookeeper的session的建立与关闭是十分消耗性能的。因为在zookeeper中，所有的写操作都要在法定人数的server端操作成功才会同步到所有server。这是zookeeper的写瓶颈所在。另外，假设zookeeper集群的连接客户端非常多，而客户端仅仅只是连接Observer ZooKeeperServer 去读取数据并不涉及写操作时，只建立本地会话能够大大提升性能。

因此在3.5.0后引入一个local session（本地会话）的概念。local session只存在于与客户端连接的server中。

local session有以下特点：

当localSessionsUpgradingEnabled 被禁用时，即local session不允许被升级为全局会话，那么：

1、local session不能建立临时节点

2、当会话丢失时，客户端并不能向集群的其他server重建同样的会话。因此local session只存在于之前所连接的server中。但是，这并不意味着当tcp链接断开后，客户端就只能新建一个session了。只要在timeout时间内，客户端重新连接上同一个server，那么session也能够得到保持。

3、local session的信息只由被连接的server维护，并不会通知到集群leader，同样的，session的状态信息也不会被持久化到磁盘。

4、心跳维持、过期和其他session状态由当前的server维护。

为什么要禁用？

在想要处理大量客户端的大型部署中，我们知道客户端通过观察者进行连接，而观察者应该仅是本地会话。因此，这更像是防止有人意外创建大量临时节点和全局会话的防护措施。

当localSessionsUpgradingEnabled 启用时，即local session允许被升级为全局会话，那么local session发生以下情况时会被自动升级为global session（全局会话）：

1、当local session创建一个临时节点时，local session会先升级为global session再行创建。为什么创建临时节点就要升级为全局会话呢？原因是临时节点的创建在很大程度上取决于全局会话。从数据一致性的角度出发，那么当local session创建临时节点时，不同节点的数据就会不一致。从管理的角度出发，临时节点的删除依赖于集群中的leader。leader需要知道session的生命周期以便当session结束时能够删除临时节点，但是local session并不被leader知晓。

如果请求升级，则将会话从本地集合中删除，同时保留相同的会话ID。

当客户端请求与服务端A建立session时，服务端A会发送session id和password给客户端，同时提交一个createSession给leader。如果在客户端收到返回数据而leader未接收到createSession时，客户端断开连接重连上服务端B，此时服务端B会拿着客户端给的session id发送一个验证包给leader。如果在验证数据包到达之前leader提交了由A发出的CreateSession，则客户端将可以连接。否则，客户端将使会话过期，因为法定人数尚未得知该会话。此时，如果客户端也尝试再次连接回A，则该会话已从本地会话跟踪器中删除。因此，A将需要将验证数据包发送给领导者。处理过程与B相同。