前言
阿粉公司有一个 Web 管理系统，使用 Tomcat 进行部署。由于是后台管理系统，所有的网页都需要登录授权之后才能进行相应的操作。
起初这个系统的用的人也不多，为了节省资源，这个系统仅仅只是单机部署。后来随着用的人越来越多，单机已经有点扛不住了，于是阿粉决定再部署了一台机器。
这时后端系统有两台服务，于是我们使用 Nginx 作为反向代理，整体架构图如下：
这个架构图想必大家应该比较熟悉，现在主流的 Web 系统应该都是这么部署。
经过一些调试之后，在一个夜深人静的晚上，阿粉将这套系统部署到了生产。本以为没有什么事的，很稳的交给测试小姐姐开始测试。
这一测，出了大问题！测试小姐姐反馈，登录过后，没过一会又需要登录，操作好几次都是这样。
阿粉检查了一下，系统应用，配置什么也没问题，那到底哪里出了问题？
这个时候组长刚准备下班，看到我们这里有问题，于是过来了看了一下。简单了解的一下基本情况，很快就找到了问题的原因，然后在 Nginx 端修改了下配置，重启解决了问题。
分布式一致性 Session
解决完问题，组长坐下给阿粉解释了问题原因：分布式一致性 Session。
原先我们登录之后将会把用户登录信息放在 Session 中，用户每次操作首先先校验 Session 是否存在用户信息，如果不存在将会强制让用户先去登录。
原先架构的中我们只有一台应用系统，所有操作都在一台 Tomcat 上，这当然没有什么问题。
但是现在我们部署了两台系统，由于 Nginx 使用默认负载均衡策略（轮询），请求将会按照时间顺序逐一分发到后端应用上。
也就是说刚开始我们在 Tomcat1 登录之后，用户信息放在 Tomcat1 的 Session 里。过了一会，请求又被 Nginx 分发到了 Tomcat2 上，这时 Tomcat2 上 Session 里还没有用户信息，于是又要登录。
另外由于我们系统采用单点登录的方式，Tomcat2 登录之后会将 Tomcat1 登录信息失效，于是乎等到 Nginx 再把流量分发到 Tomcat1 时，Session 中用户登录信息已经失效，又要重新登录。
知道了问题，阿粉当然想知道解决办法了，于是组长教了阿粉分布式一致性 Session 四种解决办法，阿粉给大家整理了一下：
下面阿粉将会以阿粉跟组长对话的形式，讲解分布式一致性 Session 解决办法。
Session 复制
组长：
如果此时 Tomcat1 Session 存在用户信息，而 Tomcat2 上没有存在。
这时如果我们将 Tomcat1 的 Session 复制到 Tomcat2 上，后面 Nginx 将请求转发到 Tomcat2 上，由于 Tomcat2 存在 Session ，这时就不需要再重新登录了。
架构图如下：
一致性 Session-Session 复制
Tomcat 的 Session 复制的配置，网上有比较多的例子，这里阿粉就不再贴了，感兴趣的同学可以自行搜索一下。
阿粉：
对的，这种方式挺好啊。Tomcat 就支持这种方式，我们只需要修改 Tomcat 配置就好，我们应用代码都不用修改了。
组长：
说的对，但是这种方式还是有很多缺点。
第一，Session 复制传输需要占用内网带宽。
第二，我们的例子就只有两台机器，这个复制性能还可以。但是假设我们有 N 台机器，那么每次复制都要复制给 N-1 台机器，如果机器很多，可能会形成网络风暴，复制性能也会呈指数级下降。
第三， Tomcat 需要保存所有的 Session 数据，这个方案的 Session 存储在内存中，容易受到机器的总内存的限制。我们没办法通过加机器的方式水平扩展，我们能做的方式就是加大机器内存。但是机器内存越大，价格真的很贵！！！
所以不推荐使用这种方案。
Session 前端存储
阿粉：
恩，这个方案确实有点不靠谱~
哎，有了！我们的 Session 里面其实就是存了用户的信息，那我现在不存 Tomcat Session 里，我把信息拿出来，存到浏览器的 Cookie 中。
这样，每个用户浏览器存储自己的 Cookie 信息，服务端就不需要存储，这就解决了 Session 复制方案的缺陷了。
接下来用户每次请求都把这个 Cookie 给我发过来，我判断 Cookie 里面用户信息不就好了。
架构图如下：
一致性 Session-Session 前端存储
