分布式session存储方案

分布式session存储方案

 

Session Stick

 

Session Stick 方案即将客户端的每次请求都转发至同一台服务器，这就需要负载均衡器能够根据每次请求的会话标识（SessionId）来进行请求转发

 

 

这种方案实现比较简单，对于Web服务器来说和单机的情况一样。但是可能会带来如下问题：

 

1. 如果有一台服务器宕机或者重启，那么这台机器上的会话数据会全部丢失。

 

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

 

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

 

 

 

Session Replication 

 

Session Replication 的方案则不对负载均衡器做更改，而是在Web服务器之间增加了会话数据同步的功能，各个服务器之间通过同步保证不同Web服务器之间的Session数据的一致性

 

 

Session Replication 方案对负载均衡器不再有要求，但是同样会带来以下问题：

 

1. 同步Session数据会造成额外的网络带宽的开销，只要Session数据有变化，就需要将新产生的Session数据同步到其他服务器上，服务器数量越多，同步带来的网络带宽开销也就越大。

 

2. 每台Web服务器都需要保存全部的Session数据，如果整个集群的Session数量太多的话，则对于每台机器用于保存Session数据的占用会很严重。

 

 

 

Session 数据集中存储 

 

Session 数据集中存储方案则是将集群中的所有Session集中存储起来，Web服务器本身则并不存储Session数据，不同的Web服务器从同样的地方来获取Session

 

 

相对于Session Replication方案，此方案的Session数据将不保存在本机，并且Web服务器之间也没有了Session数据的复制，但是该方案存在的问题在于：

 

1. 读写Session数据引入了网络操作，这相对于本机的数据读取来说，问题就在于存在时延和不稳定性，但是通信发生在内网，则问题不大。

 

2. 如果集中存储Session的机器或集群出现问题，则会影响应用。

 

 

 

Cookie Based 

 

Cookie Based 方案是将Session数据放在Cookie里，访问Web服务器的时候，再由Web服务器生成对应的Session数据

 

 

但是Cookie Based 方案依然存在不足：

 

1. Cookie长度的限制。这会导致Session长度的限制。

 

2. 安全性。Seesion数据本来是服务端数据，却被保存在了客户端，即使可以加密，但是依然存在不安全性。

 

3. 带宽消耗。这里不是指内部Web服务器之间的宽带消耗，而是数据中心的整体外部带宽的消耗。

 

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

 

 

总结

前面四个方案都是可行的，但是对于大型网站来说，Session Sticky和Session数据集中存储是比较好的方案。

 

参考

http://blog.csdn.net/t894690230/article/details/50477923

 

《大型网站系统与Java中间价实践》