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