乐趣区

关于android:zookeeper原理篇Zookeeper会话机制

会话

在 Zookeeper 中,会话是个很重要的概念之一,客户端与服务端之间的任何交互操作都和会话非亲非故,其中蕴含 zookeeper 的长期节点的生命周期、客户端申请执行以及 Watcher 告诉机制等。接下来,咱们从 全局的会话状态变动 创立会话 再到 会话治理 三个方面来看看 Zookeeper 是如何解决会话相干的操作

会话状态

客户端须要与服务端创立一个会话,这个时候客户端须要提供一个服务端地址列表,“host1 : port,host2: port ,host3:port”, 依据地址开始创立 zookeeper 对象,这个时候客户端的状态则变更为 CONNECTION, 同时客户端会根据上述的地址列表,依照程序的形式获取 IP 来尝试建设网络连接,直到胜利连贯上服务器,这个时候客户端的状态就能够变更为CONNECTED。在 zookeeper 服务端提供服务的过程中,有可能遇到网络稳定等起因,导致客户端与服务端断开了连贯,这个时候客户端会进行从新连贯操作,这个时候的状态为CONNECTION, 当连贯再次建设后,客户端的状态会再次更改为CONNECTED,也就是说只有在 zookeeper 运行期间,客户端的状态总是能放弃在CONNECTION 或者是 CONNECTED。当然在建设连贯的过程中,如果呈现了连贯超时、权限查看失败或者是在建设连贯的过程中,咱们被动退出连贯操作,这个时候客户端的状态都会变成CLOSE 状态。

会话创立

Session

Session 是 Zookeeper 中会话的实例载体,一个 Session 则是指代一个客户端会话。一个会话必须蕴含以下几个根本的属性:

  • SessionID : 会话的 ID,用来惟一标识一个会话,每一次客户端建设连贯的时候,Zookeeper 服务端都会给其调配一个全局惟一的sessionID
  • TimeOut:一次会话的超时工夫,客户端在结构 Zookeeper 实例的时候,会配置一个 sessionTimeOut 参数用于指定会话的超时的工夫。Zookeeper 服务端会依照连贯的客户端发来的 TimeOut 参数来计算并确定超时的工夫
  • TickTime:下一次会话超时的工夫点,为了不便 Zookeeper 对会话进行所谓的分桶策略进行治理,同时也能够实现高效的对会话的一个检查和清理。TickTime是一个 13 位的 Long 类型的数值,个别状况下这个值靠近TimeOut,然而并不齐全相等
  • isCloseing:用来标记以后会话是否曾经处于被敞开的状态。如果服务端检测到以后会话的超时工夫曾经到了,就会将 isCloseing 属性标记为曾经敞开,这样当前即便再有这个会话的申请拜访也不会被解决

SessionID

SessionID 作为一个全局惟一的标识,咱们能够来探索下 Zookeeper 是如何保障 Session 会话在集群环境下仍然能保障全局唯一性的:

sessionTracker 初始化的时候,会调用 initializeNextSession 来生成 session,算法大略如下:

public s ta tic long initializeNextSession(long id) {
    long nextSid = 0;
    nextSid = (System .currentTim eM illis() « 24) » 8;
    nextSid = nextSid | (id « 5 6);
    return nextSid;
} }

从这段代码,咱们能够看到 session 的创立大略分为以下几个步骤:

1. 获取以后工夫的毫秒示意

咱们假如以后 System.currentTimeMills()获取的值是 1380895182327,其 64 位二进制示意为:

00000000 00000000 00000001 01000001 10000011 11000100 01001101 11110111

  1. 接下来左移 24 位, 咱们能够失去后果:

01000001 100000011 11000100 01001101 11110111 00000000 00000000 00000000,能够看到低位曾经把高位补齐,剩下的低位都应用了 0 补齐

3. 右移 8 位,后果变成了:

00000000 01000001 100000011 11000100 01001101 11110111 00000000 00000000

4. 计算机器码标识 ID

在 initializeNextSession 办法中,呈现了一个 id 变量,这个变量就是生成的 SID 的值,而 SID 在部署的时候就是咱们在 myid 中配置的值,个别是一个整数,假如此时的值为 2,转为 64 位二进制示意:

00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000010

此时发现高位简直都是 0,进行左移 56 位当前,失去值如下:

00000010 00000000 00000000 00000000 00000000 00000000 00000000 00000000

5. 将后面第三步和第四步失去的后果进行 | 操作:

能够失去后果为:

00000010 01000001 10000011 11000100 01001101 11110111 00000000 00000000

这个时候咱们能够失去一个单机中惟一的序列号 ID,整个算法大略能够了解为,先通过高 8 位确定机器当前,前面的 56 位依照毫秒进行随机,能够看进去以后的算法! 还是蛮谨严的,基本上看不出来什么显著的问题,然而其实也有问题的,其中咱们能够看到,zk 抉择了以后机器工夫内的毫秒作为基数,然而如果工夫到了 2022 年 4 月 8 号当前,System . currentTimeMillis ()的值会是多少呢?

Date d =  new Date (2022-1900 f 3,8);
System. out. p rin tln (Long. toBinaryString(d .getTime()));

打印进去的后果为:

0000000000000000000000011000000000000100110000010000010000000000

接着咱们左移 24 位当前会发现,这个时候的值仍然是个正数,所以咱们为了保障不会呈现正数的状况,解决方案如下:

public static long initializeNextSession(long id {) {
long nextSid = 0;
nextSid = (System .currentTim eM illis() « 24) > » 8;
nextSid = nextSid | (id « 5 6);
return nextSid;
} }

这样就能够防止生成的时候呈现正数了

SessionTracker

SessionTracker 是 Zookeeper 中的会话管理器,负责整个 zk 生命周期中会话的 创立 治理 清理 操作,而每一个会话在 Sessiontracker 外部都保留了三份,大体如下:

1.sessionsWithTimeout 这是一个 ConcurrentHashMap<Long,Integer> 类型的数据结构,用来治理会话的超时工夫,这个参数会被长久化到快照文件中去

2.sessionsById 是一个 HashMap<Long,Integer> 类型的数据结构,用于依据 sessionId 来治理 session 实体

3.sessionsSets 同样也是一个 HashMap<Long,Integer> 类型的数据结构,用来会话超时的时候进行归档,便于进行会话复原和治理

会话创立

创立会话的过程,大体能够分为几个步骤,别离是解决 ConnectRequest 申请、创立会话、处理器链路解决和响应,在 zk 服务端中,首先是 NIOServerCnxn 来负责承受来自客户端的会话创立申请,并且进行反序列化工作,而后开始调配超时工夫。调配结束后,会开始创立 sessionId, 并且将其注册到 SessionsById 和 sessionsWithTimeOut,进行激活,这个时候就能够思考解决流转。

会话治理

Zookeeper 中的会话治理次要是 SesssionTracker 负责的,外部应用了一个非凡的机制,称之为 分桶策略,所谓分桶策略,其实是将相似的会话放在一个区块中进行治理,以便于 zookeeper 对会话进行不同区块的隔离以及同一区块的对立解决

从图中咱们能够看到,所有的会话都调配在了不同的区块中,分配原则是每个会话的下个超时的工夫点,ExpiractionTime是指最近一次可能过期的工夫点,每一个会话的 ExpiractionTime 的计算形式如下:

ExpiractionTime = CurrentTime + SessionTimeout

然而不要遗记了,Zookeeper 的 Leader 服务器在运行期间会定期检查是否超时,这个定期的工夫距离为 ExpiractionInterval,单位是秒,默认状况下是 tickTime 的值,即 2000 毫秒进行一次查看,残缺的ExpiractionTime 的计算形式如下:

ExpirationTime_  = CurrentTime + SessionTimeout ;
ExpirationTime =  (ExpirationTime_ / Expirationlnterval+ 1) x Expirationlnterval ;
会话激活

同样的,在整个 zookeeper 运行过程中,客户端会在超时工夫外向服务端发送 PING 申请来放弃时效性,俗称心跳检测,而服务端在承受到了客户端的心跳申请后须要再次激活会话状态,这个过程称之为TouchSession,流程如下:

1. 测验会话是否曾经被敞开,Leader 会去查看会话是否被敞开,如果曾经敞开,不会再去激活该会话

2. 如果会话没有被敞开,则开始计算下一次的超时工夫 Expiration_New,而计算的过程则是应用下面的公式

3. 计算完新的超时工夫当前,会去获取会员原来的超时工夫,并且依据工夫来定位原来寄存的区块

4. 接着,从该区块中找到会话,进行会话迁徙,放入新的 Expiration_New 对应的区块中,如图所示:

通过以上的步骤,根本曾经实现了会话的激活,而每一次心跳的检测,则是进行了一次会话激活操作,在整个 Zookeeper 运行过程中,个别如下两个操作才会导致会话激活:

1. 当客户端向服务端发送申请的时候,包含读写申请,都会被动触发一次会话激活

2. 如果客户端在 sessionTimeOut / 3 工夫范畴内尚未和服务器之间进行通信,即没有发送任何申请,就会被动发动一个 PING 申请,去触发服务端的会话激活操作

除此之外,因为会话之间的激活是依照分桶策略进行保留的,因而咱们能够利用此策略优化对于会话的超时查看,在 Zookeeper 中,会话超时查看也是由 SessionTracker 负责的,外部有一个线程专门进行会话的超时查看,只有顺次的对每一个区块的会话进行查看,因为分桶是依照ExpriationInterval 的倍数来进行会话散布的,因而只有在这些工夫点查看即可,这样能够缩小查看的次数,并且批量清理会话,实现较高的效率。

会话清理

会话查看操作当前,当发现有超时的会话的时候,会进行会话清理操作,而 Zookeeper 中的会话清理操作,次要是以下几个步骤:

1. 因为会话清理过程须要肯定的工夫,为了保障在清理的过程中,该会话不会再去承受和解决发来的申请,因而,在会话查看结束后,SessionTracker会先将其会话的 isClose 标记为 true,接着为了保障在进行会话敞开的过程中,在整个集群中都失效,Zookeeper 应用了提交的形式,交给 PreRequestProcessor 处理器进行解决

2. 在某个会话生效后,这个会话创立的相干长期节点列表都应该被删除,因而在删除会话之前,须要先找到与改会话绝对应的长期节点列表,在 Zookeeper 的内存数据库中,会为每一个会话独自保留一份由该会话保护的长期节点汇合,然而咱们须要思考一些非凡状况,例如 在删除会话的时候,有没处理完毕的删除节点的申请,而这个被删除的节点刚好又是会话对应的长期节点,或者这个时候正在解决长期节点创立的申请,而且也是以后会话的申请。这个时候咱们必须思考解决计划,防止出现数据不统一的状况,而第一种状况,则是避免反复删除,咱们只须要先把申请对应的节点删除,再去删除对应的列表即可,而第二种状况,咱们也须要先执行增加节点的申请,保障节点不会呈现删除脱漏即可。

3. 当会话对应的长期节点列表找到后,Zookeeper 会将列表中所有的节点变成删除节点的申请,并且丢给事物变更队列 OutStandingChanges 中,接着 FinalRequestProcessor 处理器会触发删除节点的操作,从内存数据库中删除。

4. 当会话对应的长期节点被删除当前,就须要将会话从 SessionTracker 中移除了,次要从 SessionByIdsessionsWithTimeOut 以及 sessionsSets 中将会话移除掉,当所有操作实现后,清理会话操作实现,这个时候将会敞开最终的连贯NioServerCnxn

会话重连

在 Zookeeper 运行过程中,也可能会呈现会话断开后重连的状况,这个时候客户端会从连贯列表中依照程序的形式从新建设连贯,直到连贯上其中一台机器为止,这个时候可能呈现两种状态,一种是失常的连贯CONNECTED,这种状况是 Zookeeper 客户端在超时工夫内连贯上了服务端,而超时当前才连贯上服务端的话,这个时候的客户端会话状态则为EXPIRED,被视为非法会话。

而在重连之前,可能因为其余起因导致的断开连接,即 CONNECTION_LESS,会抛出异样 org.apache.zookeeper.KeeperException$ConnectionLossException,咱们须要捕捉异样,并且在重连胜利后,收到 None-SyncConnection 告诉外面进行 setData 的解决操作即可。而在这个过程中,会话可能会呈现两种状况:

会话生效:SESSION_EXPIRED

会话生效个别产生在 ConnectionLoss 期间,客户端尝试开始重连,然而在超时工夫当前,才与服务端建设连贯的状况,这个时候服务端就会告诉客户端以后会话曾经生效,咱们只能抉择从新创立一个会话,进行数据的解决操作

会话转移:SESSION_MOVED

会话转移也是在重连过程中常产生的一种状况,例如在断开连接之前,会话是在服务端 A 上,然而在断开连接重连当前,最终与服务端 B 从新复原了会话,这种状况就称之为会话转移。而会话转移可能会带来一个新的问题,例如在断开连接之前,可能刚刚发送一个创立节点的申请,申请发送结束后断开了,很短时间内再次重连上了另一台服务端,这个时候又发送了一个一样的创立节点申请,这个时候一样的事物申请可能会被执行了屡次。因而在 Zookeeper3.2 版本开始,就有了会话转移的概念,并且封装了一个 SessionMovedExection 异样进去,在解决客户端申请之前,会查看一遍,申请的会话是不是以后服务端的,如果不存在以后服务端的会话,会间接抛出 SessionMovedExection 异样,当然这个时候客户端曾经断开了连贯,承受不到服务端的异样响应了。

退出移动版