Spring Session教程
Spring Session常见的应用场景
Spring Session的执行流程
Session会话管理

Session会话管理

Web中的Session和Cookie回顾

1. Session机制

由于HTTP协议是无状态的协议,一次浏览器和服务器的交互过程就是:

浏览器:你好吗?

服务器:很好!

这就是一次会话,对话完成后,这次会话就结束了,服务器端并不能记住这个人,下次再对话时,服务器端并不知道是上一次的这个人,所以服务端需要记录用户的状态时,就需要用某种机制来识别具体的用户,这个机制就是Session。

2. Cookie

服务端如何识别特定的客户?

这个时候需要使用Cookie。每次HTTP请求的时候,客户端都会发送相应的Cookie信息到服务端。

实际上大多数的应用都是用 Cookie 来实现Session跟踪的,第一次创建Session时,服务端会在HTTP协议中向客户端 Cookie 中记录一个Session ID,以后每次请求把这个会话ID发送到服务器,这样服务端就知道客户端是谁了。

3. url重写

那么如果客户端的浏览器禁用了 Cookie 怎么办?

一般这种情况下,会使用一种叫做URL重写的技术来进行session会话跟踪,即每次HTTP交互,URL后面都会被附加上一个诸如 sessionId=xxxxx 这样的参数,服务端据此来识别客户端是谁。

在Web项目开发中,Session会话管理是一个很重要的部分,用于存储与记录用户的状态或相关的数据。

通常情况下session交由容器(tomcat)来负责存储和管理,但是如果项目部署在多台tomcat中,则session管理存在很大的问题;

多台tomcat之间无法共享session,比如用户在tomcat A服务器上已经登录了,但当负载均衡跳转到tomcat B时,由于tomcat B服务器并没有用户的登录信息,session就失效了,用户就退出了登录;

 一旦tomcat容器关闭或重启也会导致session会话失效;

因此如果项目部署在多台tomcat中,就需要解决session共享的问题。

Session会话管理及带来的问题

在Web项目开发中,Session会话管理是一个很重要的部分,用于存储与记录用户的状态或相关的数据。

通常情况下session交由容器(tomcat)来负责存储和管理,但是如果项目部署在多台tomcat中,则session管理存在很大的问题:

• 多台tomcat之间无法共享session,比如用户在tomcat A服务器上已经登录了,但当负载均衡跳转到tomcat B时,由于tomcat B服务器并没有用户的登录信息,session就失效了,用户就退出了登录;

• 一旦tomcat容器关闭或重启也会导致session会话失效;

因此如果项目部署在多台tomcat中,就需要解决session共享的问题。

Session会话共享方案

第一种:是使用容器扩展插件来实现,比如基于Tomcat的tomcat-redis-session-manager插件,基于Jetty的jetty-session-redis插件、memcached-session-manager插件;这个方案的好处是对项目来说是透明的,无需改动代码,但是由于过于依赖容器,一旦容器升级或者更换意味着又得重新配置;其实底层是,复制session到其它服务器,所以会有一定的延迟,也不能部署太多的服务器。

第二种:是使用Nginx负载均衡的ip_hash策略实现用户每次访问都绑定到同一台具体的后台tomcat服务器实现session总是存在这种方案的局限性是ip不能变,如果手机从北京跳到河北,那么ip会发生变化;另外负载均衡的时候,如果某一台服务器发生故障,那么会重新定位,也会跳转到别的机器。

第三种:是自己写一套Session会话管理的工具类,在需要使用会话的时候都从自己的工具类中获取,而工具类后端存储可以放到Redis中,这个方案灵活性很好,但开发需要一些额外的时间。

第四种:是使用框架的会话管理工具,也就是我们要介绍的Spring session,这个方案既不依赖tomcat容器,又不需要改动代码,由Spring session框架为我们提供,可以说是目前非常完美的session共享解决方案。

全部教程