欢迎您访问程序员文章站本站旨在为大家提供分享程序员计算机编程知识!
您现在的位置是: 首页

负载均衡集群中的session解决方案

程序员文章站 2022-07-11 11:59:28
...

1.什么是Session

1.1 什么是Session

用户使用网站的服务,基本上需要浏览器与Web服务器的多次交互。HTTP协议本身是无状态的,需要基于HTTP协议支持会话状态(Session State)的机制。而这样的机制应该可以使Web服务器从多次单独的HTTP请求中看到”会话”,也就是知道哪些请求来自哪个会话的。
具体实现方式为:在会话开始时,分配一个唯一的会话标识(SessionId),通过Cookie把这个标识告诉浏览器,以后每次请求的时候,浏览器都会带上这个会话标识来告诉Web服务器请求是属于哪个会话的。在Web服务器上,各个会话有独立的存储,保存不同的 会话的信息。如果遇到禁用Cookie的 情况,一般的做法就是把这个会话放到URL的参数中,
负载均衡集群中的session解决方案

如下图所示 的网站中,如果我第一次访问网站时 请求落到了左边的服务器,那么我的Session就创建在左边的服务器上,如果我们不做处理 ,就不能保证 接下来的请求每次都落在同一边的服务器上,这就是Session问题。
负载均衡集群中的session解决方案
我们看看以下的集中解决方案:

2.Session的解决方案

2.1 Session Sticky

在单机的情况下,会话保存在单机上,请求也都是由这个机器处理,所以不会有问题。Web服务器编程多台以后,如何保证同一个会话的请求都在同一个Web服务器上处理,那么对这个会话的个体来说,与之前单机的情况是一样的。
如果要这样,就需要负载均衡器能够根据每次请求的会话标识来进行请求转化,如下图,称为Session Sticky。
负载均衡集群中的session解决方案
这个方案本身非常简单,对于Web服务器来说,该方案和单机的情况是一样的,只是我们在负载均衡上做了”手脚”。这个方案可以让通过同样Session的请求每次 都发送到同一个服务器端处理,非常利于针对Session进行服务端本地的缓存。不过也带来了如下几个问题:
- 如果有一台Web服务器宕机或者重启,那么这台机器上的会话数据会丢失。如果会话中有登录状态数据,那么用户就要重新登录了。
- 会话标识是应用层的信息,那么负载均衡器要将同一个会话的请求都保存到同一个Web服务器上的话,就要进行应用层的解析,这个开销比第4层的交换要大。
- 负载均衡器变为了一个有状态的节点,要将会话保存到具体Web服务器的映射。和无状态的节点相比,内存消耗会更大,容灾方面会更麻烦。

以nginx为例实现方法:

   upstream nginx.example.com
       { 
                server 192.168.74.235:80; 
                server 192.168.74.236:80;
                ip_hash;
       }
       server
       {
                listen 80;
                location /
                {
                        proxy_pass
                       http://nginx.example.com;
                }
    }

ip_hash 不能在以下情况下使用:
- nginx不是最前端的服务器
ip_hash 要求nginx一定是最前端的服务器,否则nginx得不到正确的ip,就不能根据ip作hash.

  • nginx 的后端还有其他 方式的负载均衡
    假如nginx后端又有其它负载均衡,将请求又通过另外的方式分流了,那么某个客户端的请求肯定不能定位到同一台session应用服务器上。这么算起来,nginx后端只能直接指向应用服务器,或者再搭一个squid,然后指向应用服务器。最好的办法是用 location作一次分流,将需要session的部分请求通过ip_hash分流,剩下的走其它后端去。

2.2 Session Replication

如下图:
负载均衡集群中的session解决方案
可以看到,在Session Replication方式中,不再要求负载均衡器来保证同一个会话的多次请求必须到同一个Web服务器上。而我们的Web服务器之间则增加了会话的同步。通过同步就保证了不同Web服务器之间的Session数据的一致。
一般的应用容器都支持Session Replication方式,与Session Sticky 方案相比,Session Replication 方式对负载均衡器没有那么多的要求。不过本身也会存在一些问题,我们来看一下下面的问题:
- 同步Session 数据造成了网络带宽的开销。只要Session 数据有变化,就需要将数据同步到所有其他机器上,机器数 越多,同步带来的网络带宽开销就越大。
- 每台Web服务器都要保存所有的Session 数据,如果整个集群的Session数据很多的话,每台机器用于保存的Session数据内容占用会很严重。
这就是Session Replicaiton方案。这个方案是靠应用容器来完成Session 的复制,从而使得应用解决Session 问题的,应用本身并不关心这个事情。不过,这个方案不适合集群机器数多的场景。如果只有几台机器,用这个方案是可以的。

tomcat配置参考:https://blog.csdn.net/shiyong1949/article/details/78197848

2.3 Session数据集中存储

同样是希望同一个会话的请求发到不同Web服务器上,刚才的Session Replication是一种方案,还有另一种方案就是把Session 集中存储起来,然后不同Web服务器从同样的地方来获取Session,大概的结构如下图:
负载均衡集群中的session解决方案
该方案存在的问题:
- 读写Session 数据引入了网络操作,这相对于本机的数据读取来说,问题就在于存在时延和不稳定性,不过我们的通信基本都是发生在内网,问题不大。
- 如果集中存储 Session 的机器 或者集群有问题,就会永祥我们应用

相对于Session Replication ,当Web服务器数量比较大、Sessison数比较大 的时候,这个集中存储防范的优势是非常明显的。

实现的技术方案:
- Tomcat 使用redis实现session共享https://blog.csdn.net/fd2025/article/details/80014228
- Spring session + redis:https://www.cnblogs.com/westward/articles/6978906.html
- shiro session + redis: https://www.cnblogs.com/shihaiming/p/6406640.html
- SSO+redis :https://blog.csdn.net/WuCourage/article/details/77802812

2.4 Cookie Based

Cookie Based 方案是要介绍的最后一个解决Session问题的方案。这个方案对于同一个会话的不同请求也是不限制具体处理机器的。和Session Replication 以及Session数据集中管理的方案不同,这个方案是通过Cookie来传递Session的数据的。
负载均衡集群中的session解决方案
从上图可以看到,我们的Session数据放在Cookie中,然后在Web服务器从Cookie中生成对应的Session数据。不过,这种方案依然存在不足:
- Cookie长度的限制。我们知道Cookie是有长度的,而这也 会限制Session 数据的长度。
- 安全性: Session 数据本来都是服务器端数据,而这个方案是让这些服务端数据到了外部网络及客户端,因此存在安全上的问题。我们可以对写入的Cookie的Session数据做加密。
- 带宽消耗:这里指的不是内部 Web服务器之间的带宽消耗,而是我们数据 中心的整体外部带宽的 消耗。
- 性能影响:每次HTTP请求和响应都带有Session数据,对Web服务器来说,在 同样的处理情况下,响应的结构输出越少,支持的并发请求就会越多。

负载均衡集群中的session解决方案
喜欢的话关注一下,有趣又内涵的文档将第一时间发送。