微服务下分布式架构会话管理

前言

浏览器和应用服务器之间通过HTTP协议进行通信,而HTTP协议是无状态的,也就是每个请求之间是相互独立不关联的,但是随着应用业务发展,服务器需要按照用户的一系列业务操作向用户提供特定的的内容,这时候需要通过保存用户状态,将用户的请求关联起来,Session管理正是这一问题的解决方案。

早期的Web应用基本都是采用的是单架构,所有的用户请求都是由唯一的服务器进行响应处理,所以只要把保存用户信息和状态的Session对象,存放在应用服务器内存中,就能轻松解决。随着Web应用的发展,用户访问量和业务复杂度与日俱增,为了突破瓶颈,继而演变出了集群和分布式两种架构类型,本篇主要讲在集群以及分布式架构下会话的管理。

Session原理

image

浏览器首次访问我们系统web服务器,后端服务器端会响应一个sessionId,并且把这个sessionId传输给浏览器,并将sessionId保存cookie到浏览器本地。

后面的访问请求会把这个cookie的sessionId以请求头的方式传给后端服务器,后端服务器就可以获取到请求头中sessionId,然后在服务器中查找Session对象,服务器中有没有此sessionId对应的用户,这样就能标识出哪个用户,如果有用户相关的业务,就是利用这个sessionId返回用户相关的业务。

该方案的实质就是浏览器客户端本地保存了sessionId,服务器端保存了sessionId和用户信息映射,这样就实现了web应用有状态化。

会话管理方式

1、 Session复制

image

Session复制本质是利用了应用服务器自身的特性,如:tomcat。需要修改一下tomcat的相关配置,使同一集群应用服务器之间进行session复制,使每台服务器上面保存的用户session一致。

缺点:

  • session之间的复制就会占用很大的网络带宽,系统负担较大

  • session复制是有时间延迟的

  • 服务器的内存是有限的,代表着session存放是有限的

2、 Session会话保持

Session粘性就是利用负载均衡器的特性,把同一个ip的同一个用户都定向发送到同一个服务器上

image

用户A访问系统被负载均衡器一直分配到服务器A上,这样也就保证了用户一直在同一个服务器中进行查找session,保证了用户session一致性。实现该方案可以使用硬件会话保持,比如F5设备,软件会话保持,比如Nginx做会话保持。我行现在微信银行就是使用该方案,微信银行现在是集群部署,使用F5硬件做会话保持。

缺点:

  • 服务器的内存是有限的,代表着session存放是有限的

  • 这个方案适用集群架构,但不适用分布式架构

  • 一旦服务器拓展数量,session就会出现混乱

3、Cookie方案

cookie方案是客户端的方案,就是把session信息保存到cookie中,即用户信息保存到cookie中,这样就不需要服务器保存session(用户信息)了。每次请求时,把此cookie传给服务器端,这样服务器端就知道是哪个用户了。

此方案比较实现比较简单,而且还不占用服务器端的内存资源。但是此方案的问题很大:

  • cookie的大小存在限制能记录的信息不能超过限制;

  • 每次请求都要传输cookie影响性能;

  • cookie可被修改或者存在破解的可能,导致cookie不能存重要信息,安全系数不够。

4、Session外部存储

上面的方案都是服务器端改造的方案,session都是存储到服务器内存中的,缺点比较明显。所以又衍生出一种新的方案,将Session保存到硬盘中,外部存储中

image

这个方案的核心就是把session的存储的地方改造到一个独立的媒介中,这样就不需要和应用服务器耦合了,客户端传入sessionId时,用户信息的映射关系直接到这个独立媒介中去查询。比如存储到数据库或者存储到独立的缓存服务器。

4.1、数据库存储

将Session信息保存到数据库中,一般集群或者分布式架构或者数据库集群,保证了session能够存储到集群中的所有服务器,同时也保证了session的一致性。

优点:session持久化到数据库中,保存到硬盘,一般不会丢失。

缺点:性能比较差,将session保存到数据库需要频繁的访问数据库,会对数据库造成很大压力

4.2、Redis存储

redis存储方案一般结合spring session方式,把session存储到redis中。

image

这个方案是spring提供的一套Session管理方案,通过一个SessionFilter将所有请求拦截下来,对session进行管理,此方案的好处就是不与应用服务器耦合,可以部署到任何web应用服务器中。redis也是高性能的缓存服务器,且可持久化。这个方案也是官方推荐的。

总结

上面介绍了比较常用的Session管理方案,渠道系统对会话管理案例比较多,像网银系统、微信银行等系统属于集群部署,使用的是F5硬件做会话保持,但是分布式系统,像手机银行,权益平台使用的就是Session存储到Redis方案,不同的系统可以根据系统的具体情况做选择。

推荐阅读

字节跳动总结的设计模式 PDF 火了,完整版开放分享

刷Github时发现了一本阿里大神的算法笔记!标星70.5K

如果能听懂这个网约车实战,哪怕接私活你都可以月入40K

为什么阿里巴巴的程序员成长速度这么快,看完他们的内部资料我懂了

程序员达到50W年薪所需要具备的知识体系。

关于【暴力递归算法】你所不知道的思路

看完三件事❤️

如果你觉得这篇内容对你还蛮有帮助,我想邀请你帮我三个小忙:

点赞,转发,有你们的 『点赞和评论』,才是我创造的动力。

关注公众号 『 Java斗帝 』,不定期分享原创知识。

同时可以期待后续文章ing

你可能感兴趣的:(微服务下分布式架构会话管理)