WatchStor.com — 领先的中文存储网络媒体 | 51CTO旗下网站

技术文档 > 集群 > 正文
解决应用服务器集群的Session问题
作者: 佚名 2018-05-24 15:00 【全球CTO俱乐部】

先来看一下什么是Session。

用户使用网站的服务,基本上需要浏览器与Web服务器的多次交互。HTTP协议本身是无状态的,需要基于HTTP协议支持会话状态(SessionState)的机制。而这样的机制应该可以使Web服务器从多次单独的HTTP请求中看到“会话”,也就是知道请求是来自哪个会话的。

具体实现方式为:在会话开始时,分配一个唯一的会话标识(SessionId),通过Cookie把这个标识告诉服务器,以后每次请求的时候,浏览器都会带上这个会话标识来告诉Web服务器请求是属于哪个会话的。在Web服务器上,各个会话有独立的存储,保存不同会话的信息。如果遇到禁用Cookie的情况,一般的做法就是把这个会话标识放到URL的参数中。


单台应用服务器

当一个带有会话标识的HTTP请求到了Web服务器后,需要在HTTP请求的处理过程中找到对应的会话数据(Session)。而问题在于会话数据是需要保存在单机上的。

在面对应用服务器集群时,如果我第一次访问网站时请求通过负载均衡设备落到了服务器A,那么我的Session就创建在服务器A上了,如果我们不做处理,就不能保证接下来的请求每次都落在服务器A上了。


应用服务器集群

1.SessionSticky


使负载均衡器能够根据每次请求的会话标识来进行请求转发。

需要在负载均衡服务器上保存会话到具体Web服务器的映射。


SessionSticky

这种方法非常简单,但是有以下几个问题:

1.如果有一台Web服务器宕机或者重启,那么这台机器上的会话数据会丢失。如果会话中有登陆状态信息,那么用户就要重新登录了。

2.会话标识是应用程序的信息,负载均衡服务器要将同一个会话的请求都保存到一个Web服务器上的话需要进行应用层(OSI模型第7层)的解析,这个开销比第4层(传输层)的交换大。

3.负载均衡器变成了有状态的节点,要保存会话到Web服务器的映射,比无状态节点内存消耗更大,容灾会更麻烦。

2.SessionReplication

Web服务器之间增加了会话数据的同步,应用服务器集群中的每一台服务器上都有一份会话数据。


SessionReplication

但是也带来了一些问题:

1.同步Session数据造成了网络带宽的开销。只要Session数据有变化就需要同步,机器数越多,同步带来的网络带宽开销越大。

2.每台Web服务器都保存所有额Session数据,在很多人同时访问网站的时候,每台机器用于保存Session数据的内容占用会很严重。

3.Session数据集中存储

不同的服务器从同样的地方来获取Session。会话请求经过负载均衡服务器后,不会被固定在同样的Web服务器上,而是放在了一个集中存储的地方。Web服务器使用Session数据时,也是从这个集中存储Session数据的地方来读取。


Session数据集中存储

这个方案解决了第一种方案的内存问题,也第二种方案占用网络带宽的情况要好。但是依然存在一些问题:

1.读写Session数据引入了网络操作,相对于本机的数据读取来说,问题在于存在时延和不稳定性。

2.如果集中存储Session的机器或者集群有问题,就会影响我们的应用。

4.CookieBased

把Session数据放在Cookie中,在Web服务器上从Cookie中生成对应的Session数据。


CookieBased

这个方案不会依赖外部存储系统,也就不存在从外部系统获取、写入数据的网络时延和不稳定性了。

不过依然存在不足:

1.Cookie长度的限制。Cookie长度会限制Session数据的长度。

2.安全性。Session数据是服务端数据,这个方案让服务端数据到了外部网络和服务端。

3.带宽消耗。数据中心整体外部带宽的消耗。

4.性能影响。每次HTTP请求和响应都带有Session数据。

小结

这4种方案都是可用的方案,不过对于大型网站来说,SessionSticky和Session数据集中存储是比较好的方案,而这两个方案又各有优势,需要在具体的场景中做出选择和权衡。


标签:大型机(主机) 集群 

LecVideo