session分布式处理

session分布式处理

标签（空格分隔）： 分布式

---

1. Session复制

在支持Session复制的Web服务器上, 通过修改服务器配置, 可以实现将Session同步到其它Web服务器上, 达到每个Web服务器上都保存一直的Session

• 优点: 代码不需要做支持和修改.
• 缺点: 需要依赖支持的Web服务器, 一旦更换成不支持的Web服务器就不能使用了, 在数据量很大的情况下比较浪费网络资源, 而且会导致延迟 .
• 适用场景: 只适用于Web服务器比较少且Session数据量少的情况.
• 可用方案: tomcat-redis-session-manager.
• 注意: 在使用request.getSession().setAttribute()的时候, 如果需要放入对象 需要将该对象实现序列化接口, 否则会报错.

工作机制:

1. request请求开始.
2. 调用request.getSession()时, RedisSessionManager会先finaSession(id), 找到返回Session, 没找到就CreateSession, 并且序列化到Redis.
3. session.setAttribute()判断set的值和以前的值是否一致, 不一致就序列化Session到Redis. ( set的是一个对象, 比如LoginUser的email属性, 这个时候对象实例的没有变化的, 并不会序列化到Redis, 但会在afterRequest中会做修正. )
4. session.removeAttribute会序列化到Redis.
5. 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集中管理更加的可靠, 使用也最多.