微服务下的分布式session管理

╰半夏微凉° 2022-01-12 04:37 266阅读 0赞

> **享学课堂特邀作者：老顾**
> 
> **转载请声明出处！**

# 前言 #

今天老顾带着大家了解一下**session会话在微服务架构中采用的技术方案**，以及 **企业应用中需要注意的问题。**

# session作用 #

我们知道在web应用中，**web服务器和浏览器之间是用http协议进行通信的**，而**http协议是无状态**的，也就是**每个请求都是独立**的。如：用户看一条A新闻，不管是谁看到的都是一模一样的新闻。也就是**跟用户是谁没有任何关系**。

但业务自身的发展，需要把**不同的内容展示给不同的用户**，即**信息和用户状态关联**起来。如：历史阅读列表---列出用户之前看的新闻。这个需求就是跟用户相关，**每个用户看到的历史阅读列表都是不一样的。**

**Session的产生**就是为了解决这个问题，把**服务器和客户端之间进行状态保持**的解决方案。

# session原理 #

浏览器在第一次访问web服务器，**服务器端会响应一个sessionId，并且把这个sessionId传输给浏览器，并以cookie保存sessionId到浏览器本地**。

以后的访问会**把这个cookie的sessionId以请求头的方式传给服务器**，这样服务器就可以拿着**这个sessionId进行查找，服务器中有没有此sessionId对应的用户**，这样就能标识出哪个用户，如果有用户相关的业务，就是**利用这个sessionId返回用户相关的业务**。

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

# 单体架构 #

在早期的单体架构中，也就是**只有一台web服务器**，虽然在web应用中也进行的分层设计，但其实本质是在代码逻辑级别，**本身还是一个应用而已**（或者说就是一个war/jar包）。

这个时期的session都是**保存在本地的web服务器内存中**，非常简单就能保持用户状态。

# 集群/分布式架构 #

随着业务的**复杂度升高，和对应用性能、高可用的需求，系统演变成了集群和分布式架构**。

> **集群架构**可以看服务器A和服务器B，部署同一个应用A，就是为了提升性能和高可用目的；服务器C是部署了另一个应用B，**代表系统不是单一业务**，而是多个应用集合的，**即分布式架构。**

这个架构中，我们之前的session方案就会有问题，因为**服务器端的session是存放在本地内存中**的。请看下面的流程

> 1、用户A第一次访问系统，由负载均衡器映射**到服务器A中**
> 
> 2、会在**服务器A的本地内存中，存放着session**
> 
> 3、用户A第二次访问系统，又被**随机分配到了服务器B中**
> 
> 4、但服务器B中是**没有存放用户A的session的**，所以此sessionId在服务器B中找不到对应的session，就会**以为用户没有登录**，就会引导用户去登录
> 
> 5、这样就导致**session不一致的问题**。

# session复制 #

**session复制方案是一个服务器端的方案**，对客户端是透明的，客户端不需要改变什么。看架构图

这个方案本质是利用了**应用服务器自身的特性**，如：tomcat。修改一下tomcat的配置文件，就是让**应用服务器之间进行session复制**，这样就可以达到**每个服务器都有一样的session。**

> 这个方案2-3个服务器还行，但服务器一旦多起来，就会有问题。
> 
> **1、session之间的复制就会占用很大的网络带宽**
> 
> **2、session复制是有时间延迟的**
> 
> **3、服务器的内存是有限的，代表着session存放是有限的**

# session粘性 #

这个方案就利用**负载均衡器的特性**，把同一个浏览器的同一个用户都定向发送到同一个服务器上。看架构图

上图的核心思路，用户甲访问系统被负载均衡器**一直分配到服务器A上**，这样也就保证了用户一直在同一个服务器中进行查找session，**保证了用户session一致性**。

不过此方案也存在一些问题：

> **1、服务器的内存是有限的，代表着session存放是有限的**
> 
> **2、这个方案适用集群架构，但不适用分布式架构**
> 
> **3、一旦服务器拓展数量，session就会出现混乱**

# cookie方案 #

之前的方案都是在服务器端进行改造的，**cookie方案是客户端的方案**，就是把session信息**保存到cookie**中，即用户信息保存到cookie中，这样**就不需要服务器保存session**（用户信息）了。每次请求时，**把此cookie传给服务器端，这样服务器端就知道是哪个用户了**。

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

> 1、cookie在客户端是有限的，存储容量也是很小的
> 
> 2、安全是很有问题的，因为保存在本地，很容易被人拿到

# session外部存储 #

之前的服务器端改造的方案，**session都是存储到本地内存中的，导致一些问题。** 此外部存储就是把思路进行改变，**让session的存储与应用服务器隔离出来**，看架构图

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

# **数据库存储** #

存储媒介的选择之一就是数据库，就是**把session信息存储到数据库中。**

好处就是session持久化到数据库中，**不会丢失**。但**性能比较差**，因为session的访问是非常频繁的，会对数据库造成很大压力，

# Memcache存储 #

此方案就是把**session存储到memcache中**，Memcache-Tomcat-Session就是利用tomcat实现session的集中化管理的开源方案，**修改tomcat配置就行了**，使用扩展的sessionManager替换tomcat默认的Session管理器。

memcache性能比较高，但此**方案和tomcat强耦合了**，不适合其他的应用服务器，如：jetty。而且**memcache无持久化，一旦重启，session就丢失了**。

# Redis存储 #

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

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

# **总结** #

到这里老顾已经介绍了常用的session管理方案，**最终推荐的是spring session方式进行session管理**，存储在redis中。小伙伴们看到这里是不是感觉蛮好了，可以在企业中进行应用了？

> 如果企业小，项目不复杂，是可以应用了。

但如果系统很复杂，有**很多业务系统都是有session**的，那么**如何对session从业务角度进行管理呢？上面我们介绍cookie方案，小伙伴们有没有考虑到JWT Token方案**，jwt方案又会怎么样？留下二个问题，请小伙伴们仔细思考下。请持续关注老顾的文章，谢谢！！！

转载于:https://juejin.im/post/5d08b4185188250a8b1fd66f