一:Web中的Session和Cookie回顾
1.Session机制
由于HTTP协议是无状态的协议,一次浏览器和服务器的交互过程就是:
浏览器:你好吗?
服务器:很好!
这就是一次会话,对话完成后,这次会话就结束了,服务器端并不能记住这个人,下次再对话时,服务器端并不知道是上一次的这个人,所以服务端需要记录用户的状态时,就需要用某种机制来识别具体的用户,这个机制就是Session。
2.Cookie
服务端如何识别特定的客户?
这个时候需要使用Cookie。每次HTTP请求的时候,客户端都会发送相应的Cookie信息到服务端。
实际上大多数的应用都是用 Cookie 来实现Session跟踪的,第一次创建Session时,服务端会在HTTP协议中向客户端 Cookie 中记录一个Session ID,以后每次请求把这个会话ID发送到服务器,这样服务端就知道客户端是谁了。
如图:
(1)浏览器第一次访问服务器
(2)浏览器第二次访问服务器(也就是浏览器以前访问过这个服务器)
3.url重写
那么如果客户端的浏览器禁用了 Cookie 怎么办?
一般这种情况下,会使用一种叫做URL重写的技术来进行session会话跟踪,即每次HTTP交互,URL后面都会被附加上一个诸如 sessionId=xxxxx 这样的参数,服务端据此来识别客户端是谁。
二:Session会话管理及带来的问题
在Web项目开发中,Session会话管理是一个很重要的部分,用于存储与记录用户的状态或相关的数据。
通常情况下session交由容器(tomcat)来负责存储和管理,但是如果项目部署在多台tomcat中,则session管理存在很大的问题
- 多台tomcat之间无法共享session,比如用户在tomcat A服务器上已经登录了,但当负载均衡跳转到tomcat B时,由于tomcat B服务器并没有用户的登录信息,session就失效了,用户就退出了登录
- 一旦tomcat容器关闭或重启也会导致session会话失效
问题如图所示:(session丢失的根本原因不是因为切换服务器的问题,根本原因在这两个tomcat的 jvm 中,因为 jvm 是处于相对独立的位置(所以真正丢失session原因的是我们后台服务器sessionId和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共享解决方案。
(只列出了四种,但不只有四种)