session分布式处理
标签（空格分隔）： 分布式
1. Session复制
在支持Session复制的Web服务器上, 通过修改服务器配置, 可以实现将Session同步到其它Web服务器上, 达到每个Web服务器上都保存一直的Session
- 优点: 代码不需要做支持和修改.
- 缺点: 需要依赖支持的Web服务器, 一旦更换成不支持的Web服务器就不能使用了, 在数据量很大的情况下比较浪费网络资源, 而且会导致延迟 .
- 适用场景: 只适用于Web服务器比较少且Session数据量少的情况.
- 可用方案: tomcat-redis-session-manager.
- 注意: 在使用
request.getSession().setAttribute()的时候, 如果需要放入对象 需要将该对象实现序列化接口, 否则会报错.
工作机制:
request请求开始.- 调用
request.getSession()时,RedisSessionManager会先finaSession(id), 找到返回Session, 没找到就CreateSession, 并且序列化到Redis. session.setAttribute()判断set的值和以前的值是否一致, 不一致就序列化Session到Redis. ( set的是一个对象, 比如LoginUser的email属性, 这个时候对象实例的没有变化的, 并不会序列化到Redis, 但会在afterRequest中会做修正. )session.removeAttribute会序列化到Redis.request结束, 会回调RedisSessionManager.afterRequest, 做两个关键的事情
- 根据判断session有没有发生变化, 有则序列化到redis
- 更新redis的expore, 过期时间, 只要访问过, 保证session会话不过期.
2. Session粘贴
将用户的每次请求都通过某种方法强制分发到某一个Web服务器上, 只要这个Web服务器上存储了对应的Session数据, 就可以实现会话跟踪.
- 优点: 使用简单, 没有额外开销.
- 缺点: 一旦某个Web服务器重启或者宕机, 相应的Session数据会丢失, 而且需要依赖负载均衡机制.
- 使用场景: 对稳定性要求不是很高的业务情景.
3. Session集中管理
在单独的服务器或者服务器集群上使用缓存技术, 如Redis存储Session数据, 集中管理所有的Session, 所有为Web服务器都从这个存储介质中存取对应的Session, 实现Session共享.
- 优点: 可靠性高, 减少Web服务器的资源开销.
- 缺点: 实现上有些复杂, 配置较多.
- 使用场景: Web服务器较多, 要求高可用的情况.
- 可用方案: 开源方案Spring Session, 也可以自己实现, 主要是重写
HTTPServletRequesWrapper中的getSession方法.
4. 基于Cookie管理
每次发起请求的时候都需要将Session数据放到Cookie中传递给服务端.
- 优点: 不需要依赖额外的外部存储, 不需要额外配置.
- 缺点: 不安全, 容易被盗取或篡改; 浏览器规定一个站点的Cookie最多不超过20个.
- 适用场景: 数据不重要, 不敏感且数据量小的情况.
总结
四种方式中,相对来说Session集中管理更加的可靠, 使用也最多.