Session一致性

Session 复制

如果此时 Tomcat1 Session 存在用户信息，而 Tomcat2 上没有存在。
这时如果我们将 Tomcat1 的 Session 复制到 Tomcat2 上，后面 Nginx 将请求转发到 Tomcat2 上，由于 Tomcat2 存在 Session ，这时就不需要再重新登录了。

缺点
这个方案并不适合集群机器数多的场景。

Session 前端存储

我们的 Session 里面其实就是存了用户的信息，那我现在不存 Tomcat Session 里，我把信息拿出来，存到浏览器的 Cookie 中。
这样，每个用户浏览器存储自己的 Cookie 信息，服务端就不需要存储，这就解决了 Session 复制方案的缺陷了。
接下来用户每次请求都把这个 Cookie 给我发过来，我判断 Cookie 里面用户信息不就好了。

缺点
这种方案，首先你要想好加密方案。
用户信息可是我们的敏感数据，不能让别人轻易的窃取或者篡改数据了。
除了这个，这个方案每次请求都要携带 Cookie 传输，这会占用外网的带宽，如果 Cookie 过大，会增大网络的开销。
另外，我们存储的数据大小，容易受到 Cookie 限制。
所以这种还是不怎么常用，不过也是一种思路。

Session 粘滞（Sticky Sessions）

Nginx 会使用请求者的 IP 来做 Hash，然后分发到一台机器上，这样可以保证同一 IP 的请求都落在同一台 Tomcat 上。
上面这种方式我们使用 Nginx 四层负载均衡方式，其实 Nginx 还可以做到七层负载均衡方式，也就是使用 Http 协议中的一些业务属性来做 Hash，常见的有 userId,loginId等等。
缺点
负载均衡器变为了一个有状态的节点，要将会话保存到具体Web服务器的映射，因此内存消耗会更大，容灾会更麻烦。

后端集中存储

使用这种方案，上没有 Session 丢失的风险，当然前提是 Redis 不能宕机。
另外后期如果应用可以直接水平扩展。
如果后面应用的请求量很大，一台 Redis 扛不住了，那我们可以其实可以做集群扩展，根据缓存 Key 做路由。

总结

• Session 复制：利用 Tomcat 等 Web 容器同步复制
• Session 前端存储：利用用户浏览器中 Cookie 保存 Session 信息
• Session 粘滞方案：利用 Nginx 可以做四层 Hash 或七层 Hash 的特性，保证用户的请求都落在同一台机器上
• Session 后端集中存储方案：利用 Redis 集中存储 Session，Web 应用重启或扩容，Session 也无需丢失。