Session共享的解决办法

本文探讨了网站集群中Session共享的问题,介绍了无状态和有状态请求的区别,并提出了四种解决方案:session同步、Session黏着、信息存Cookie及单点登录。重点讨论了各自的优缺点。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

问题的由来:访问一个网站时,有两类请求。一种请求叫做无状态的请求,一种请求叫做有状态。

无状态,例如:登录页面,类似这种页面,哪个tomcat给我们响应都是一样的,不需要区分。这是我们最喜欢的。集群的动态伸缩性(增加节点,移除节点)。

有状态,例如:系统登录后,假如用户的请求被转发到tomcat1上,这时系统会写一个当前用户的信息放入session中。这种情况就称为有状态的,问题就来了。nginx负载均衡后,下一次用户的请求就被转发tomcat2上。tomcat2上没有session。系统就会要求用户去登录,这显然是不合理的。把这个问题称作session共享问题。

       

解决的办法:
1 .      session同步

tomcat支持动态将某个tomcat下的session复制到其他的tomcat中。但是这个方式是早期的企业级应用习惯的方式。现在很少使用。

这种方式在集群数量很少时,结果还是可以的。但如果集群数量庞大。都需要复制session,这时会因为网络延迟,或者session的内容非常大。都会造成隐患,这时可能读到脏数据。

2       Session黏着-放在服务端

ip地址或者域名地址进行hash;或者uri进行hash

缺点:用户浏览器的IP地址hash以后满足单调性。会可能造成资源的分配不均衡,负载均衡就达不到到目的。有的服务器负载过重,有的服务器负载过轻,显然没有充分利用资源。
因为uriip地址相应数量多,变化就多,因此uri-haship-hash分布更均衡些。 uri-hash需要第三方软件支持pcre-8.02.tar.gzNginx_upstream_hash-0.3.1.tar.gz

3       将信息放到cookie-放在客户端

session存在服务器端,会对服务器产生压力。如果将信息保存到cookie中,减轻了服务器的压力,同时每个客户端的压力也很小。因为只保存自己的信息。这种方式在实际的开发中广泛的采用。

缺点:cookie可以被禁用,cookie要随着浏览器传递,增大了传输的内容,cookie大小有限制。


4       终极的解决方案-SSO单点登录

session从系统中独立出来。Apacheshiro顶级安全框架,它的session管理就是独立出来的。目前主流做法是利用redis作为session管理的实现,因为redis访问极其快速。
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值