解决应用服务器集群后的Session问题

一、Session Sticky：通过负载均衡器能够根据每次请求的会话标识来进行请求转发（称为Session Sticky方式）。

让同样的Session 的请求每次都发送到同一个服务器端处理，利于针对Session 进行服务器端本地的缓存。

缺点：

1、如果其中一台宕机，会话数据将丢失。

2、会话标识是应用层的信息，那么负载均衡器要将同一个会话的请求都保存到同一个Web服务器上，就需要进行应用层（第7层）的解析，这个开销比第4层的交换要大。

3、负载均衡器变为了一个有状态的节点，要将会话保存到具体Web服务器的映射。和无状态的节点相比内存消耗会更大，容灾方面会更麻烦。

二、Sesssion Replication

Session复制，在Web 服务器之间增加会话数据的同步，保证每个Web 服务器都有一样的Session

缺点：

1、同步 Session 数据造成了网络带宽的开销。只要Session数据有变化，就需要将数据同步到所有其他机器上，机器数越多，同步带来的网络带宽开销就越大。

2、每台Web服务器都要保存所有的Session数据，如果整合集群的Session数很多，每台机器用于保存Session数据的内容占用会很严重。

三、Session 数据集中存储

存储在分布式缓存或者数据库中

缺点：

1、读写Session数据引入了网络操作，存在时延和不稳定性，不过通信基本发生在内网，问题不大

2、当存储Session的机器或者集群有问题，聚会影响我们的应用

四、Cookie Based

通过Cookie 传递Session数据。

缺点：

1、Cookie长度限制，限制了Session数据的长度

2、安全性问题。不过我们可以采用对Session数据加密

3、带宽消耗

4、性能影响。每次HTTP请求和响应都带有Session数据，对Web服务器来说，同样的处理情况下，响应的结果输出越少，支持的并发请求就会越多。