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

前言

浏览器和应用服务器之间通过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