学习springSession复习cookie与session的关系以及Session会话管理及带来的问题

一：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共享解决方案。

（只列出了四种，但不只有四种）