session 分布式处理

Session 复制

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

  • 优点:代码上不需要做支持和修改。
  • 缺点:需要依赖支持的 Web 服务器,一旦更换成不支持的 Web 服务器就不能使用了,在数据量很大的情况下不仅占用网络资源,而且会导致延迟。
  • 适用场景:只适用于Web服务器比较少且 Session 数据量少的情况。
  • 可用方案:开源方案 tomcat-redis-session-manager,暂不支持 Tomcat8。

Session 粘滞

将用户的每次请求都通过某种方法强制分发到某一个 Web 服务器上,只要这个 Web 服务器上存储了对应 Session 数据,就可以实现会话跟踪。

  • 优点:使用简单,没有额外开销。
  • 缺点:一旦某个 Web 服务器重启或宕机,相对应的 Session 数据将会丢失,而且需要依赖负载均衡机制。
  • 适用场景:对稳定性要求不是很高的业务情景。

Session 集中管理

在单独的服务器或服务器集群上使用缓存技术,如 Redis 存储 Session 数据,集中管理所有的 Session,所有的Web服务器都从这个存储介质中存取对应的 Session,实现 Session 共享。

  • 优点:可靠性高,减少 Web 服务器的资源开销。
  • 缺点:实现上有些复杂,配置较多。
  • 适用场景:Web服务器较多、要求高可用性的情况。
  • 可用方案:开源方案 Spring Session,也可以自己实现,主要是重写 HttpServletRequestWrapper 中的 getSession 方法。

这种方式每次发起请求的时候都需要将 Session 数据放到 Cookie 中传递给服务端。

  • 优点:不需要依赖额外外部存储,不需要额外配置。
  • 缺点:不安全,易被盗取或篡改;Cookie 数量和长度有限制,需要消耗更多网络带宽。
  • 适用场景:数据不重要、不敏感且数据量小的情况。

总结

这四种方式,相对来说,Session 集中管理 更加可靠,使用也是最多的。

上次更新: 2018-12-25 0:20:40