本文参考曾宪杰著作《大型网站系统与Java中间件实践》
HTTP 协议本身是无状态的,需要基于 HTTP 协议支持会话状态的机制。在会话开始时,分配一个唯一的会话标识(SessionId),通过 Cookie 把这个标识告诉浏览器,以后每次请求的时候,浏览器都会带上这个会话标识来告诉服务器请求是属于哪个会话的。
当服务器变成集群部署的时候,通过负载均衡的方式分发请求到不同的机器上。如果第一次访问网站时生成的 Session 存在 A 服务器,第二次请求的时候可能就分发到 B 服务器上去了,此时就会出现登录失败的问题。针对这个又如下几种解决方案。
Session Sticky
单机模式下,会话保存在单机上,请求也在单机上。如果在负载均衡的时候,通过 Session 能知道这个 Session 保存在哪台服务器上,然后再转发到对应的服务器上去,此时就能解决 Session 找不到的问题。
不足之处:
- 如果集群中有一台服务器宕机或者重启,那么这台服务器上的会话数据就会丢失,此时保存在这个服务器上的登录用户就要重新登录。
- 会话标识是应用层的信息,负载均衡器要将同一个会话的请求都保存到同一个服务器上,就要进行应用层(第七层)解析,这个开销比第四层要大。
- 负载均衡器变成了一个有状态的节点,要将会话保存到具体的服务器的映射。和无状态的节点相比,内存消耗会更大,容灾方面会更麻烦。
Session Replication
依靠应用容器间的会话复制实现不同节点间 Session 的同步,这样不管请求到哪个服务器,都可以正常访问。
不足之处:
- 同步 Session 数据造成网络带宽的开销,机器越多,开销越多。
- 每台服务器都保存所有的 Session 数据,如果数据量很多会导致每台机器保存的 Session 内容占用严重。
Session 数据集中存储
将 Session 数据集中存储到一起,所有的服务器都向这个 Session 集合获取数据。
不足之处:
- 读写 Session 数据引入了网络操作,有延迟和不稳定的风险。
- 如果集中存储 Session 的机器或者集群出现故障,会导致整个应用无法使用。
Cookie Based
将 Session 数据存储在 Cookie 中,客户端每次请求都将 Session 带到服务端去。
不足之处:
- Cookie 长度有限制。
- 安全性会有一定问题。
- 带宽消耗。
- 性能影响。每次 HTTP 请求和响应都带有 Session 数据,对 Web 服务器来说,在同样的处理情况下,响应的结果输出越少,支持的并发请求就会越多。