分布式一致性Session实现

原文来源:https://juejin.im/post/5f10f3b25188252e40124d6d -- 楼下小黑哥

分布式一致性Session

用户登录后，会将信息放在session里面，如果是单机模式下，session一直都是可用的。用户每次操作首先先校验 Session 是否存在用户信息，如果不存在将会强制让用户先去登录。

nginx负载均衡

分布式下访问

Session一致性的四种解决方案

①Session复制
②前端/客户端存储
③Session粘滞
④后端集中存储
####总览
图片说明

Session复制

如果此时 Tomcat1 Session 存在用户信息，而 Tomcat2 上没有存在。
这时如果我们将 Tomcat1 的 Session 复制到 Tomcat2 上，后面 Nginx 将请求转发到 Tomcat2 上，由于 Tomcat2 存在 Session ，这时就不需要再重新登录了。
优点:只需要修改tomcat的配置
缺点:Session同步占用内网带宽、
但是假设我们有 N 台机器，那么每次复制都要复制给 N-1 台机器，如果机器很多，可能会形成网络风暴，复制性能也会呈指数级下降、
第三， Tomcat 需要保存所有的 Session 数据，这个方案的 Session 存储在内存中，容易受到机器的总内存的限制。我们没办法通过加机器的方式水平扩展，我们能做的方式就是加大机器内存。但是机器内存越大，价格真的很贵！！！

Session 前端存储

图片说明

Session粘滞

刚才应该看到了，我只是对 Nginx 的配置做了一些修改，然后这个问题就解决了吧。
其实这是因为我修改 Nginx 默认的负载均衡策略，使用 IP Hash 的方式。
Nginx 会使用请求者的 IP 来做 Hash，然后分发到一台机器上，这样可以保证同一 IP 的请求都落在同一台 Tomcat 上。

后端集中存储

上面几种的方式我们都是把 Session 存储在应用内存上，应用机器只要重启，Session 就会丢失。
为了这个解决这个问题，我们将 Session 单独存起来，保存到 Redis 或者 MySQL 中。
不过由于 Session 需要过期失效的特性，不需要持久化保存，所以这里我建议使用 Redis 来保存。
这样架构就变成下方这样的：
图片说明

总结

最后总结一下，当我们后端 Web 应用扩展到多台后，我们就会碰到分布式一致性 Session 的问题，主流解决方案有四种：

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

上面四种方案，优先推荐第四种。
当然第四种方案需要一定的开发工作量，前期还没改造的过程可以选择第三种方案中间过渡。