应用服务器的高可用设计主要基于服务无状态这一特性，但事实上，业务总
是有状态：
在电商网站，需要有购物车记录用户的购买信息，用户每次购买请求都是向购物车中增加商品
在社交类网站，需要记录用户的当前登录状态、最新发布的消息及好友状态等，用户每次刷新页面都需要更新这些信息
Web 应用中将这些多次请求修改使用的上下文对象称作会话(Session)。单机情况下，Session 可由部署在服务器上的Web 容器( 如Tomcat) 管理。
在使用负载均衡的集群环境中，由于负载均衡服务器可能会将请求分发到集群中的任何一台应用服务器上，所以保证每次请求依然能够获得正确的Session比单机时要复杂很多。
集群环境下,Session 管理主要有以下几种手段：
1 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管理。
