前言

阿粉公司有一个 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 前端存储