应用服务器集群下的session问题解决

前言：由于http协议是无状态的，所以http的协议需要支持会话状态机制；session是产生于服务器端用来保存用户和服务器会话状态的。而传统的单击型web服务器，session是保存在单击上，无需考虑会话session会出现差异而导致用户和服务器的会话发生异常。

问题：由于集群，用户访问的服务器可能存取不确定性，如何保证用户的session不发生丢失和异常，保证会话都是关联到同一个session上呢？（解决办法：保证session同一服务器上/访问的服务器上有同一个session）

以下的方案都是建立在Browser-负载均衡器-n个应用服务器 基础上

1、Session Sticky

由负载均衡器将用户的请求从第一次开始访问的服务器，在session未失效的前提，之后关联固定在上一次访问的服务器上，即同样的session请求送到同一个服务器端处理

带来问题：1、某台服务器宕机就可能丢失数据；2、负载均衡器要解析应用层，开销大，内存消耗大，容灾麻烦

2、Session Replication

将session复制到所有的应用服务器上，不适合集群数量过多的场景

带来问题：1、同步session造成的开销网络宽带开销大，其中一个session数据有变就要同步到其他所有的服务器上；2、每台web服务器都要保持所有的session数据，如何访问人数过多，造成每台机器session占用的空间过多

3、Session数据集中存储

web服务器不存储session，session统一集中保存在一个机器上，web服务器要用session时从该机器上取即可，一般是内网，带宽相对SessionReplication来说少了很多

带来问题：1、由于session的读取需要通过网络，带来延时和不稳定性；2、集中存储session的机器或集群宕机也造成整个应用出现问题

4、Cookie Based

把session的数据保存在cookie里，服务器端通过cookie来生成session

带来问题：1、cookie长度有限，也限制session数据长度；2、安全性，即使通过加密，但是物理上不能接触才是安全的；3、带宽消耗，传输数据过多，外部带宽过多；4、性能影响，对web服务器来说，响应的结果数据越少，支持并发请求越多

小结：对于大型的网站来说，Session Sticky和Session数据集中存储这两种方案是常用的。根据具体的场景，在对 Session存储进行集群，我们也可以结合多种方案来实现