Tomcat 粘性session

本文介绍了两种负载均衡策略:基于request的负载均衡和基于用户的负载均衡。基于request的负载均衡通过session复制实现实时同步,确保即使部分节点失效也能维持服务;而基于用户的负载均衡采用粘性session,提高响应速度但牺牲了容错能力。

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

方案:
1、基于request的负载均衡
    该种方式下,负载均衡器 (load balancer)会根据各个node的状况,把每个 http request进行分发。使用这样的均衡策略,就必须在多个node之间复制用户的session,实时保持整个cluster的用户状态同步,这种操作被称为session复制(session replication)。Jboss的实现原理是使用拦截器(interceptor),根据用户的同步策略拦截request,做同步处理后再交给server产生响应。

     优点是客户不会被绑定都具体的node,只要还有一个node存活,用户状态都不会丢失,cluster都能够继续工作。

缺点是node之间通信频繁,响应速度有影响,多并发、高频操作的情况下性能下降比较厉害。

2、    基于用户的负载均衡
该种方式下,当用户发出第一个request后,负载均衡器动态的把该用户分配到某个节点,并记录该节点的jvm路由,以后该用户的所有request都会被绑定这个jvm路由,用户只会与该server发生交互,这种策略被称为粘性session(session sticky)。

     优点是响应速度快,多个节点之间无须通信。

缺点也很明显,某个node死掉以后,它负责的所有用户都会丢失session。


个人理解:所谓黏性session,也就是负载均衡,从客户端的角度出发,未实现真正意义上的集群,没有实现session在tomcat之间的复制。因为,cookie中记录了是来自哪个tomcat,比如来自tomcat1,如果tomcat1 down掉,那么,这个tomcat关联的所有用户都会dow掉。


黏性session(session sticky):就是常说的负载均衡,还没有实现真正意义上的集群,如果某个节点down掉,这个节点关联的所有客户端都将down掉

session复制(session replication):就是session在各个tomcat间复制,实现了真正意义上的集群,如果某个节点down掉,不会影响客户端

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值