分布式——会话

会话技术

Cookie

Cookie是通过Set-Cookie响应头和Cookie请求头将会话中产生的数据保存在客户端，是客户端的技术

工作原理

客户端向服务器发送请求，服务器获取需要保存的数据，并将需要保存的数据通过Set-Cookie响应头发送给浏览器，浏览器会以Cookie的形式保存在浏览器的内部.

当客户端再次发送请求访问服务器，服务器可以通过Cookie请求头获取上次发送给浏览器的Cookie信息，通过这种方式可以保存会话中产生的数据.

由于Cookie技术是将会话中产生的数据保存在客户端，每个客户端各自持有自己的数据，当需要时再带给服务器，因此不会发生混乱！

Session

浏览器第一次发送请求需要保存数据时,服务端获取到需要保存的数据，去服务器内部检查一下有没有为当前浏览器服务的session，如果有就直接拿过来用，如果没有session就创建一个新的session拿过来用. 接着将数据保存在Session中，做出响应

当浏览器再去访问服务器时，服务器可以从session中获取到之前为当前浏览器保存的数据，通过这种方式，也可以用来保存会话中产生的数据！

---

分布式会话管理的解决方案

容器扩展实现

大家比较容易接受的是通过容器插件来实现，比如基于Tomcat的tomcat-redis-session-manager，基于Jetty的jetty-session-redis等等。好处是对项目来说是透明的，无需改动代码。不过前者目前还不支持Tomcat 8，或者说不太完善。个人觉得由于过于依赖容器，一旦容器升级或者更换意味着又得从新来过。并且代码不在项目中，对开发者来说维护也是个问题。

自己写一套会话管理的工具类

自己写一套会话管理的工具类，包括Session管理和Cookie管理，在需要使用会话的时候都从自己的工具类中获取，而工具类后端存储可以放到Redis中。很显然这个方案灵活性最大，但开发需要一些额外的时间。并且系统中存在两套Session方案，很容易弄错而导致取不到数据。

使用框架的会话管理工具

使用框架的会话管理工具，也就是本文要说的spring-session，可以理解是替换了Servlet那一套会话管理，既不依赖容器，又不需要改动代码，并且是用了spring-data-redis那一套连接池，可以说是最完美的解决方案。当然，前提是项目要使用Spring Framework才行。

Session 粘滞（Nginx-ip_hash策略）

Nginx 会使用请求者的 IP 来做 Hash，然后分发到一台机器上，这样可以保证同一 IP 的请求都落在同一台 Tomcat 上。

架构图如下：

优点：

• 无需修改服务器端代码
• 服务端可以水平扩展

缺点：

• 增加新机器，重新Hash，导致重新登录
• 应用重启，也需要重新登录

Spring Session解决方案（推荐）

原理

Spring Session通过创建一个Filter，然后在Filter中对request和response进行包装，在包装的request中重写session保存和获取的操作，完成了将session保存到redis的操作，实现了session共享。

优点：

• 安全
• 容易水平扩展

缺点：

• 增加系统复杂度
• 需要修改服务端代码