1.什么是session?
session可以让我们知道哪些请求是来自哪个会话。
具体的实现方式为:在会话开始时,分配一个唯一的会话标示(sessionId),通过cookie把这个标示告诉浏览器,以后每次请求的时候,浏览器都会带上这个会话标示来告诉web服务器请求是属于哪个会话的。
2.解决应用服务器变为集群后的session问题
方案1:session sticky
在负载均衡上做手脚,这个方案可以让同样的session请求每次都发送到同一个服务器端处理,非常利于针对session进行服务器端本地的缓存。
打个比方来说,web服务器是我们每次吃饭的饭店,会话数据就是我们吃饭用的碗筷,要保证每次吃饭都用自己的碗筷的话,我就把餐具存在某一家,并且每次都去这家吃。
不足:
(1)如果有一台web服务器宕机或重启,造成数据丢失,用户操作记录不复存在;
(2)会话标示是应用层的信息,那么负载均衡器要将同一会话请求都保存到同一web服务器上,就需要进行应用层(第七层)的解析,这个开销比第四层的交换要大;
(3)负载均衡器变成了一个有状态的节点,内存消耗会更大,容灾方面会更麻烦。
方案2:session replication
这就好比在每家饭店都放了一套自己的餐具。这时我们的web服务器之间增加了会话数据的同步。
不足:
(1)同步session数据造成网络带宽的开销;
(2)session数很多的话,每台机器用于保存session数据的内容占用会很严重。
方案3:session数据的集中存储
与session replication不同的是web服务器之间没有了session数据的复制,而是把session数据放在了一个集中处理的地方。
不足:
(1)读写session引入了网络操作,存在时延和不稳定性;
(2)如果集中存储session的机器或者集群有问题,就会影响我们的应用。
方案4:cookie based
通过cookie来传递session数据,这就好比我们每次吃饭都把碗筷放在自己身上一样,这样我们去哪家店吃饭就可以随意选择了。
不足:
(1)cookie长度的限制;
(2)安全性;
(3)带宽消耗;
(4)性能影响。每次http请求和响应都带有session数据,对web服务器来说,在同样的处理情况下,响应的结果输出越少,支持的并发请求就会越多。