分布式 Session 问题及解决方案

本文参考曾宪杰著作《大型网站系统与Java中间件实践》

HTTP 协议本身是无状态的，需要基于 HTTP 协议支持会话状态的机制。在会话开始时，分配一个唯一的会话标识（SessionId），通过 Cookie 把这个标识告诉浏览器，以后每次请求的时候，浏览器都会带上这个会话标识来告诉服务器请求是属于哪个会话的。

当服务器变成集群部署的时候，通过负载均衡的方式分发请求到不同的机器上。如果第一次访问网站时生成的 Session 存在 A 服务器，第二次请求的时候可能就分发到 B 服务器上去了，此时就会出现登录失败的问题。针对这个又如下几种解决方案。

Session Sticky

单机模式下，会话保存在单机上，请求也在单机上。如果在负载均衡的时候，通过 Session 能知道这个 Session 保存在哪台服务器上，然后再转发到对应的服务器上去，此时就能解决 Session 找不到的问题。

不足之处：

1. 如果集群中有一台服务器宕机或者重启，那么这台服务器上的会话数据就会丢失，此时保存在这个服务器上的登录用户就要重新登录。
2. 会话标识是应用层的信息，负载均衡器要将同一个会话的请求都保存到同一个服务器上，就要进行应用层（第七层）解析，这个开销比第四层要大。
3. 负载均衡器变成了一个有状态的节点，要将会话保存到具体的服务器的映射。和无状态的节点相比，内存消耗会更大，容灾方面会更麻烦。

Session Replication

依靠应用容器间的会话复制实现不同节点间 Session 的同步，这样不管请求到哪个服务器，都可以正常访问。

不足之处：

1. 同步 Session 数据造成网络带宽的开销，机器越多，开销越多。
2. 每台服务器都保存所有的 Session 数据，如果数据量很多会导致每台机器保存的 Session 内容占用严重。

Session 数据集中存储

将 Session 数据集中存储到一起，所有的服务器都向这个 Session 集合获取数据。

不足之处：

1. 读写 Session 数据引入了网络操作，有延迟和不稳定的风险。
2. 如果集中存储 Session 的机器或者集群出现故障，会导致整个应用无法使用。

Cookie Based

将 Session 数据存储在 Cookie 中，客户端每次请求都将 Session 带到服务端去。

不足之处：

1. Cookie 长度有限制。
2. 安全性会有一定问题。
3. 带宽消耗。
4. 性能影响。每次 HTTP 请求和响应都带有 Session 数据，对 Web 服务器来说，在同样的处理情况下，响应的结果输出越少，支持的并发请求就会越多。