分布式session实现方式
- 不使用session
- 使用 JWT(Json Web Token)生成的Token 储存用户身份,然后再从数据库或者 cache 中获取其他的信息。这样无论请求分配到哪个服务器都无所谓
- tomcat+redis方案
- 方便,但是与tomcat容器重耦合
- 使用 session 的代码,跟以前一样,还是基于 tomcat 原生的 session 支持即可,然后就是用一个叫做
Tomcat RedisSessionManager
的东西,让所有我们部署的 tomcat 都将 session 数据存储到 redis 即可。
- Spring session+redis
- 给 sping session 配置基于 redis 来存储 session 数据,然后配置了一个 spring session 的过滤器,这样的话,session 相关操作都会交给 spring session 来管了。接着在代码中,就用原生的 session 操作,就是直接基于 spring sesion 从 redis 中获取数据了
注:实现分布式的会话有很多种方式,这只不过是比较常见的几种方式,tomcat + redis 早期比较常用,但是会重耦合到 tomcat 中;近些年,通过 spring session 来实现。
session的必要性
- 主要一个原因就是HTTP的无状态性
因为HTTP的无状态性,所以我们没有办法在HTTP发送请求的时候知道当前用户的状态,也就是比如说,当前是哪个用户的之类的这种信息,所以这个时候我们需要session来标识当前的状态
session原理机制
- 当程序需要为某个客户端的请求创建一个session的时候,服务器首先检查这个客户端的请求里是否已包含了一个session标识- 称为session id
- 如果已包含一个session id则说明以前已经为此客户端创建过session,服务器就按照session id把这个session检索出来使用(如果检索不到,可能会新建一个)
- 如果客户端请求不包含session id,则为此客户端创建一个session并且生成一个与此session相关联的session id,这个session id将被在本次响应中返回给客户端保存(通常保存到会话Cookie里)
session特点
- session保存的位置是在服务器端
- session一般来说是要配合cookie使用,如果是浏览器禁用了cookie功能,也就只能够使用URL重写来实现session存储的功能
- 单纯的使用session来维持用户状态的话,那么当同时登录的用户数量较多的时候,或者存在较多的数量的session会导致查询慢的问题
本质上:session技术就是一种基于后端有别于数据库的临时存储数据的技术
参考: