在sessionTracker初始化的时候,会调用initializeNextSession来生成session,算法大概如下:
-
public s ta tic long initializeNextSession(long id) {
-
long nextSid = 0;
-
nextSid = (System.currentTim eM illis() « 24) » 8;
-
nextSid = nextSid | (id « 56);
-
return nextSid;
-
} }
从这段代码,我们可以看到session的创建大概分为以下几个步骤:
1.获取当前时间的毫秒表示
我们假设当前System.currentTimeMills()获取的值是1380895182327,其64位二进制表示为:
00000000 00000000 00000001 01000001 10000011 11000100 01001101 11110111
2.接下来左移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 = newDate(2022-1900 f 3,8);
-
System. out. p rin tln ( Long. toBinaryString(d .getTime()));
打印出来的结果为:
0000000000000000000000011000000000000100110000010000010000000000
接着我们左移24位以后会发现,这个时候的值依然是个负数,所以我们为了保证不会出现负数的情况,解决方案如下:
-
publicstaticlong initializeNextSession(long id { ) {
-
long nextSid = 0;
-
nextSid = (System.currentTim eM illis() « 24) > » 8;
-
nextSid = nextSid | (id « 56);
-
return nextSid;
-
} }
这样就可以避免生成的时候出现负数了
SessionTracker
SessionTracker是Zookeeper中的会话管理器,负责整个zk生命周期中会话的创建、管理和清理操作,而每一个会话在Sessiontracker内部都保留了三份,大体如下:
1.sessionsWithTimeout这是一个ConcurrentHashMap<long,integer style=“margin: 0px; padding: 0px; box-sizing: border-box;”>类型的数据结构,用来管理会话的超时时间,这个参数会被持久化到快照文件中去</long,integer>
2.sessionsById是一个HashMap<long,integer style=“margin: 0px; padding: 0px; box-sizing: border-box;”>类型的数据结构,用于根据sessionId来管理session实体</long,integer>
3.sessionsSets同样也是一个HashMap<long,integer style=“margin: 0px; padding: 0px; box-sizing: border-box;”>类型的数据结构,用来会话超时的时候进行归档,便于进行会话恢复和管理</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;
会话激活
自我介绍一下,小编13年上海交大毕业,曾经在小公司待过,也去过华为、OPPO等大厂,18年进入阿里一直到现在。
深知大多数Java工程师,想要提升技能,往往是自己摸索成长或者是报班学习,但对于培训机构动则几千的学费,着实压力不小。自己不成体系的自学效果低效又漫长,而且极易碰到天花板技术停滞不前!
因此收集整理了一份《2024年Java开发全套学习资料》,初衷也很简单,就是希望能够帮助到想自学提升又不知道该从何学起的朋友,同时减轻大家的负担。
既有适合小白学习的零基础资料,也有适合3年以上经验的小伙伴深入学习提升的进阶课程,基本涵盖了95%以上Java开发知识点,真正体系化!
由于文件比较大,这里只是将部分目录截图出来,每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频,并且会持续更新!
如果你觉得这些内容对你有帮助,可以扫码获取!!(备注Java获取)
最后
现在其实从大厂招聘需求可见,在招聘要求上有高并发经验优先,包括很多朋友之前都是做传统行业或者外包项目,一直在小公司,技术搞的比较简单,没有怎么搞过分布式系统,但是现在互联网公司一般都是做分布式系统。
所以说,如果你想进大厂,想脱离传统行业,这些技术知识都是你必备的,下面自己手打了一份Java并发体系思维导图,希望对你有所帮助。
《一线大厂Java面试题解析+核心总结学习笔记+最新讲解视频+实战项目源码》,点击传送门即可获取!
有所帮助。
[外链图片转存中…(img-rV1h3G1P-1712119468983)]
《一线大厂Java面试题解析+核心总结学习笔记+最新讲解视频+实战项目源码》,点击传送门即可获取!