应用服务器的高可用架构设计主要基于服务无状态这一特性，但是事实上，业务总是有状态的。
在交易类的电子商务网站，需要有购物车记录用户的购买信息，用户每次购买请求都是向购物车中增加商品；
在社交类的网站中，需要记录用户的当前登录状态。
Web应用中将这些多次请求修改使用的上下文对象称作会话（Session），单机情况下，Session 可由部署在服务器上的Web容器管理。在集群环境下，由于负载均衡服务器可能会将请求分发到集群中任何一台应用服务器上，所以保证每次请求依然能够获得正确的Session 比单机时要复杂的多。
集群环境下，Session 管理的主要手段有以下几种：
- Session 复制
- Session 绑定（会话粘滞）
- Session 服务器
接下来，我们逐一进行介绍。
一、Session 复制
在服务器之间进行 Session 同步操作，每个服务器都有所有用户的 Session 信息，因此用户可以向任何一个服务器进行请求。
缺点：
- 占用过多内存
- 同步过程占用网络带宽以及服务器处理器时间
二、Session 绑定
Session 绑定（Sticky Session），又叫会话粘滞。需要配置负载均衡器，使得一个用户的所有请求都路由到同一个服务器，这样就可以把用户的 Session 存放在该服务器中。（这时负载均衡服务器必须工作在HTTP协议层上，比如反向代理负载均衡）
缺点：
当服务器宕机时，将丢失该服务器上的所有 Session。
三、Session 服务器
使用一个单独的服务器存储 Session 数据，可以使用传统的 MySQL，也使用 Redis 或者 Memcached 这种内存型数据库。由这个 Session 服务器统一管理 Session。
这种解决方案事实上是将应用服务器的状态分离，分为无状态的应用服务器和有状态的Session 服务器，然后针对这两种服务器的不同特性分别设计其架构。
优点： 为了使得大型网站具有伸缩性，集群中的应用服务器通常需要保持无状态，那么应用服务器不能存储用户的会话信息。Session Server 将用户的会话信息单独进行存储，从而保证了应用服务器的无状态。
缺点： 需要去实现存取 Session 的代码。
参考内容：
《大型网站技术架构》- 李智慧著
文章插图也均源自此书