2-2-5 Session一致性之问题现象及解决方案

一、Session 一致性的说明

1.1、Session一致性之问题现象

在这里插入图片描述

如上图
假设用户第一次页面，被Nginx 负载到了第一台tomcat机器上。这时会检测到没有登入的信息，会提示用户登入，
当用户登入后，这一台机器有用户登入的信息。

当用户发起第二次请求的时候，这时如果被 Nginx 负载到了第二台tomcat机器时，这时由于登入信息保存在第一台机器，所以又会提示用户重新登入。

反复循环。

用户退出。

1.2、Session一致性之问题剖析

出现这个问题的原因，从根本上来说是因为Http协议是⽆状态的协议。客户端和服务端在某次会话中产⽣的数据不会被保留下来，所以第⼆次请求服务端⽆法认识到你曾经来过.
Http为什么要设计为⽆状态协议？
早期都是静态⻚⾯⽆所谓有⽆状态，后来有动态的内容更丰富，就需要有状态，出现了两种⽤于保持Http状态的技术，那就是Cookie和Session。
⽽出现上述不停让登录的问题，分析如下图

在这里插入图片描述

二、Session 一致性解决方案

2.1、解决方案一： Nginx的IP_HASH负载均衡策略方案

同⼀个客户端IP的请求都会被路由到同⼀个⽬标服务器，也叫做会话粘滞

优点：

配置简单，不⼊侵应⽤，不需要额外修改代码

缺点：

服务器重启Session丢失
存在单点负载⾼的⻛险
单点故障问题

2.2、解决方案二：Session复制方案

多个tomcat之间通过修改配置⽂件，达到Session之间的复制
在这里插入图片描述

优点：

不⼊侵应⽤
便于服务器⽔平扩展
能适应各种负载均衡策略
服务器重启或者宕机不会造成Session丢失

缺点：

性能低
内存消耗 - 不能存储太多数据，否则数据越多越影响性能
延迟性

2.3、解决方案三、Session共享，Session集中存储

Session的本质就是缓存，那Session数据为什么不交给专业的缓存中间件呢？⽐如Redis
在这里插入图片描述
优点:

能适应各种负载均衡策略
服务器重启或者宕机不会造成Session丢失
扩展能⼒强
适合⼤集群数量使⽤

缺点：

对应⽤有⼊侵，引⼊了和Redis的交互代码

2.3.1 解决方案三、Session共享，Session集中存储的实现

Spring Session使得基于Redis的Session共享应⽤起来⾮常之简单

引⼊Jar

<dependency>
 <groupId>org.springframework.boot</groupId>
 <artifactId>spring-boot-starter-data-redis</artifactId>
</dependency> <dependency>
 <groupId>org.springframework.session</groupId>
 <artifactId>spring-session-data-redis</artifactId>
</dependency>

配置redis

spring.redis.database=0
spring.redis.host=127.0.0.1
spring.redis.port=6379

springboot 启动类上添加注解

2.3.2 解决方案三、Session共享，Session集中存储的源码

在这里插入图片描述
该注解可以创建⼀个过滤器使得SpringSession替代HttpSession发挥作⽤，找到那个过滤器！

在这里插入图片描述
观察其⽗类，⽗类中有Filter

在这里插入图片描述
这个Filter就是SpringSession最核⼼的地⽅

在这里插入图片描述
在过滤器中将HttpServletRequest包装

在这里插入图片描述
本质就是⼀个HtppRequest，拥有同样的⽅法，找getSession

在这里插入图片描述

回到SessionRepositoryFilter的doFilterInternal⽅法

在这里插入图片描述

2.3.3 解决方案三、Session共享，Session集中存储的原理

在这里插入图片描述