应用服务器集群的 Session 管理

===========================================================================

早期系统使用的一种服务器集群 Session 管理机制。应用服务器开启 Web 容器的 Session 复制功能，在集群中的几台服务器之间同步 Session 对象，使得每台服务器上都保存所有用户的 Session 信息,这样任何一台机器宕机都不会导致 Session 数据丢失，而服务器使用 Session 时，也只需在本机获取。

1.1 优点

虽然简单,从本机读取 Session 信息也很快速,但只能使用在集群规模比较小的情况下

1.2 缺点

• 当集群规模较大时,集群服务器间需要大量的通信进行 Session 复制,占用服务器和网络的大量资源,系统不堪负担

• 而且由于所有用户的 Session 信息在每台服务器上都有备份,在大量用户访问的情况下,甚至会出现服务器内存不够 Session 使用的情况

• 而大型网站的核心应用集群就是数千台服务器,同时在线用户可达千万,因此并不适用这种方案

2 Session 绑定(黏滞 sticky)

====================================================================================

可利用负载均衡的源地址 Hash 算法实现。

负载均衡服务器（比如 nginx）总是将来源于同一 IP 的请求分发到同一台服务器上(也可以根据 Cookie 信息将同一个户的请求总是分发到同一台服务器上，当然这时负载均衡服务器必须工作在 HTTP 协议层)。这样在整个会话期间，用户所有的请求都在同一台服务器上处理，即 Session 绑定在某台特定服务器上，保证 Session 总能在这台服务器上获取

• 利用负载均衡的会话黏滞机制将请求绑定到特定服务器

但是 Session 绑定的方案显然不符合我们对系统高可用的需求。

缺点

一旦某台服务器宕机,那么该机器上的 Session 也就不复存在了,用户请求切换到其他机器后因为没有 Session 而无法完成业务处理

因此虽然大部分负载均衡服务器都提供源地址负载均衡算法,但很少有网站利用这个算法进行 Session 管理。

3 利用 Cookie 记录 Session

===================================================================================

早期系统使用 C/S 架构,一种管理 Session 的方式是将 Session 记录在客户端,每次请求服务器的时候,将 Session 放在请求中发送给服务器,服务器处理完请求后再将修改过的 Session 响应给客户端

如今的 B/S 架构,网站没有客户端,但是可以利用刘览器支持的 Cookie 记录 Session

3.1 缺点

• 受 Cookie 大小限制,能记录的信息有限

• 每次请求响应都需要传输 Cookie,影响性能

• 如果用户关闭 Cookie,访问就会不正常

但是

3.2 优点

由于 Cookie 的

• 简单易用

• 可用性高

• 支持应用服务器的线性伸缩

• 而大部分应用需要记录的 Session 信息又比较小

因此事实上，许多网站都或多或少地使用 Cookie 记录 Session。

4 Session 服务器

===========================================================================