Session共享有多种解决方法,常用的有四种:客户端Cookie保存、服务器间Session同步、使用集群管理Session、把Session持久化到数据库。
1.客户端Cookie保存
以cookie加密的方式保存在客户端,每次session信息被写在客户端,然后经浏览器再次提交到服务器,即使两次请求在集群中的两台服务器上完成,也可以到达session共享。
优点是减轻服务器端的压力;
缺点是受到cookie的大小限制,可能占用一定带宽,因为每次请求会在头部附带一定大小的cookie信息,另外这种方式在用户禁止使用cookie的情况下无效。
传统网站一般通过将一部分数据存储在cookie中,来规避分布式环境下session的操作。这样做的弊端很多,一方面cookie的安全性一直广为垢病,另一方面cookie存储数据的大小是有限制的。随着移动互联网的发展,很多情况下还得兼顾移动端的session需求,使得采用cookie来进行session同步的方式的弊端更为凸显,分布式session正是在这种情况下应运而生的。
2.服务器间Session同步
定时同步各个服务器的session信息,此方法可能有一定延时,用户体验也不是很好。
使用主-从服务器的架构,当用户在主服务器上登录后,通过脚本或者守护进程的方式,将session信息传递到各个从服务器中,也可以手工把session文件存放的目录改为nfs网络文件系统,从而实现文件的跨机器共享(使用nfs或windows文件共享都可以,或者专用的共享存储设备)。
这样,用户访问其它的从服务器时,就可以读到session信息。
缺点:比如速度慢、不稳定等,另外,如果session信息传递是主->从单向的,会有一些风险,比如主服务器down了,其它服务器无法获得session信息。
3.把Session持久化到数据库
这种共享session的方式即将session信息存入数据库中,其它应用可以从数据库中查出session信息。目前采用这种方案时所使用的数据库一般为mysql。
利用数据库共享session的方案有一定的实用性,但也有如下缺点:
首先session的并发读写在数据库中完成,对mysql的性能要求比较高;
其次,我们需要额外地实现session淘汰逻辑代码,即定时从数据库表中更新和删除session信息,增加了工作量。
对于系统可靠性要求较高的用户,可以将session持久化到DB中,这样可以保证宕机时会话不易丢失,但缺点也是显而易见的,系统的整体吞吐将受到很大的影响。
4.使用集群管理Session
将session统一存储在缓存集群上,如memcache,这样可以保证较高的读、写性能,这一点对于并发量大的系统来说非常重要;并且从安全性考虑,session毕竟是有有效期的,使用缓存存储,也便于利用缓存的失效机制。
使用缓存的缺点是,一旦缓存重启,里面保存的会话也就丢失了,需要用户重新建立会话,可以使用缓存集群来保证缓存的稳定性。
如图(基于缓存的分布式session架构)所示,前端用户请求经过随机分发之后,可能会命中后端任意的Web Server,将session以sessionid作为key,保存到后端的缓存集群中,使得不管请求如何分配,即便是某个Web Server宕机,也不会影响其他Web Server获得 session,这样既实现了集群间的session同步,又提高了 Web Server的容错性。
Tomcat作为Web Server时,可以通过一个简单的工具memcached-session- manager9(一个Tomcat session共享解决方案), 实现基于memcache的分布式session。
可以,在容器中加入crossContext="true",可以交叉使用彼此上下文,相当于原编程中常用的application全局变量。默认设置是false,表示只能访问本WEB工程下的SESSION变量。同时也不给别的工程来访问自己。欢迎分享,转载请注明来源:夏雨云
评论列表(0条)