应用服务器集群后的Session问题及解决方案对比

01 Session定义。

Http协议本身是无状态的，为了保持会话状态需要基于Http协议支持会话状态（Session state）机制。会话开始的时候，分配一个唯一的会话标识（SessionId），通过Cookie把这个标识告诉浏览器，每次请求的时候会带上这个标识告诉Web服务器这是属于哪个会话的，在web服务器上，各个会话有独立的存储，保存不同的会话信息，遇到禁用Cookie的情况，这个做法就是把会话标识放到URL参数中。

02 集群中Session问题的产生。

当一个带有会话标识（SessionId）的http请求到达web服务器后，需要在服务器中找到对应的会话数据，如果两台机器A、B，不做任何处理的话，那就不能保证每次请求都会落在同一个服务器，这就是集群后的Session问题。

03 Session问题的解决方案。

Session问题的解决方案有四种，分别是：Sesseion Sticky、Session Replication、Session 数据集中存储、Cookie Based。下面来一一介绍：

1. 第一种：Session Sticky。通过负载均衡根据每次请求会话标识（SessionId）转发，称为Session Sticky。方案的缺点：如果其中一台服务器宕机，那么这台机器上的会话数据会消失，如果包含登录数据，那么用户就需要重新登录；会话标识是应用层的信息，负载均衡器需要把一个会话完整保存在同一个Web服务器的话，需要进行七层解析，开销比四层解析交换要大。                                                                                                                                                                                                                                 一个不恰当的比喻（一次吃饭）：负载均衡-选饭馆，Web服务器-饭馆，SessionID-桌位，会话数据-点的菜。每次吃饭的时候，先要选择餐馆，这就相当于负载设备分配一个Web服务器处理你的请求；接着，到了餐馆定下一个桌位，桌位就相当于你的SessionID，有了这个桌位，每次服务员上菜的时候都是根据你的桌位号就可以上菜了，而且不会把你的菜上给别人。
2. Session Replication。对于上面的方案，如果Session可以在web服务器之间同步的话，对于数据处理会更加方便，也就不需要负载设备根据SessionID选择Web服务器了。不过这样也造成了很多问题：同步Session数据造成的网络带宽消耗；每个Web服务器都需要保存所有的Session数据，比较庞大繁琐。

3. Session集中存储。把Session Replication继续改进，把所有的Session集中存储起来。所有的web服务器需要使用Session数据 的时候，都从一个地方获取Session。这里需要注意的问题是：Session数据需要读写操作，网络通信存在时延和不稳定性；存储的机器或集群有问题会影响应用。

4. Cookied Based。把session数据放在Cookie中，Cookie随着请求到达web服务器，web服务器根据Cookie中的信息生成Session数据。此方案的不足在于：Cookie长度本身可能有限制；客户端可以接触到服务端的数据，安全性上存在问题；C-S传输数据量加大，带宽消耗大；对web服务器的性能带来影响。