4种分布式Session的实现方式！老大直呼666...

前言

公司有一个 Web 管理系统&＃xff0c;使用 Tomcat 进行部署。由于是后台管理系统&＃xff0c;所有的网页都需要登录授权之后才能进行相应的操作。

起初这个系统的用的人也不多&＃xff0c;为了节省资源&＃xff0c;这个系统仅仅只是单机部署。后来随着用的人越来越多&＃xff0c;单机已经有点扛不住了&＃xff0c;于是我决定再部署了一台机器。

这时后端系统有两台服务&＃xff0c;于是我们使用 Nginx 作为反向代理&＃xff0c;整体架构图如下&＃xff1a;

这个架构图想必大家应该比较熟悉&＃xff0c;现在主流的 Web 系统应该都是这么部署。

经过一些调试之后&＃xff0c;在一个夜深人静的晚上&＃xff0c;我将这套系统部署到了生产。本以为没有什么事的&＃xff0c;很稳的交给测试小姐姐开始测试。

这一测&＃xff0c;出了大问题&＃xff01;测试小姐姐反馈&＃xff0c;登录过后&＃xff0c;没过一会又需要登录&＃xff0c;操作好几次都是这样。

我检查了一下&＃xff0c;系统应用&＃xff0c;配置什么也没问题&＃xff0c;那到底哪里出了问题&＃xff1f;

这个时候组长刚准备下班&＃xff0c;看到我们这里有问题&＃xff0c;于是过来了看了一下。简单了解的一下基本情况&＃xff0c;很快就找到了问题的原因&＃xff0c;然后在 Nginx 端修改了下配置&＃xff0c;重启解决了问题。

分布式一致性 Session

解决完问题&＃xff0c;组长坐下给我解释了问题原因&＃xff1a;分布式一致性 Session。

原先我们登录之后将会把用户登录信息放在 Session 中&＃xff0c;用户每次操作首先先校验 Session 是否存在用户信息&＃xff0c;如果不存在将会强制让用户先去登录。

原先架构的中我们只有一台应用系统&＃xff0c;所有操作都在一台 Tomcat 上&＃xff0c;这当然没有什么问题。

但是现在我们部署了两台系统&＃xff0c;由于 Nginx 使用默认负载均衡策略&＃xff08;轮询&＃xff09;&＃xff0c;请求将会按照时间顺序逐一分发到后端应用上。

也就是说刚开始我们在 Tomcat1 登录之后&＃xff0c;用户信息放在 Tomcat1 的 Session 里。过了一会&＃xff0c;请求又被 Nginx 分发到了 Tomcat2 上&＃xff0c;这时 Tomcat2 上 Session 里还没有用户信息&＃xff0c;于是又要登录。

另外由于我们系统采用单点登录的方式&＃xff0c;Tomcat2 登录之后会将 Tomcat1 登录信息失效&＃xff0c;于是乎等到 Nginx 再把流量分发到 Tomcat1 时&＃xff0c;Session 中用户登录信息已经失效&＃xff0c;又要重新登录。

知道了问题&＃xff0c;我当然想知道解决办法了&＃xff0c;于是组长教了我分布式一致性 Session 四种解决办法&＃xff0c;我给大家整理了一下&＃xff1a;

下面我将会以我跟组长对话的形式&＃xff0c;讲解分布式一致性 Session 解决办法。

Session 复制

组长&＃xff1a;

如果此时 Tomcat1 Session 存在用户信息&＃xff0c;而 Tomcat2 上没有存在。

这时如果我们将 Tomcat1 的 Session 复制到 Tomcat2 上&＃xff0c;后面 Nginx 将请求转发到 Tomcat2 上&＃xff0c;由于 Tomcat2 存在 Session &＃xff0c;这时就不需要再重新登录了。

架构图如下&＃xff1a;

Tomcat 的 Session 复制的配置&＃xff0c;网上有比较多的例子&＃xff0c;这里我就不再贴了&＃xff0c;感兴趣的同学可以自行搜索一下。

我&＃xff1a;

对的&＃xff0c;这种方式挺好啊。Tomcat 就支持这种方式&＃xff0c;我们只需要修改 Tomcat 配置就好&＃xff0c;我们应用代码都不用修改了。

组长&＃xff1a;

说的对&＃xff0c;但是这种方式还是有很多缺点。

第一&＃xff0c;Session 复制传输需要占用内网带宽。

第二&＃xff0c;我们的例子就只有两台机器&＃xff0c;这个复制性能还可以。但是假设我们有 N 台机器&＃xff0c;那么每次复制都要复制给 N-1 台机器&＃xff0c;如果机器很多&＃xff0c;可能会形成网络风暴&＃xff0c;复制性能也会呈指数级下降。

第三&＃xff0c; Tomcat 需要保存所有的 Session 数据&＃xff0c;这个方案的 Session 存储在内存中&＃xff0c;容易受到机器的总内存的限制。我们没办法通过加机器的方式水平扩展&＃xff0c;我们能做的方式就是加大机器内存。但是机器内存越大&＃xff0c;价格真的很贵&＃xff01;&＃xff01;&＃xff01;

所以不推荐使用这种方案。

Session 前端存储

我&＃xff1a;

恩&＃xff0c;这个方案确实有点不靠谱~

哎&＃xff0c;有了&＃xff01;我们的 Session 里面其实就是存了用户的信息&＃xff0c;那我现在不存 Tomcat Session 里&＃xff0c;我把信息拿出来&＃xff0c;存到浏览器的 COOKIE 中。

这样&＃xff0c;每个用户浏览器存储自己的 COOKIE 信息&＃xff0c;服务端就不需要存储&＃xff0c;这就解决了 Session 复制方案的缺陷了。

接下来用户每次请求都把这个 COOKIE 给我发过来&＃xff0c;我判断 COOKIE 里面用户信息不就好了。

架构图如下&＃xff1a;

组长&＃xff0c;欣赏看了一下我&＃xff1a;

对&＃xff0c;你这个方案确实可行。

不过么&＃xff0c;如果用这种方案&＃xff0c;首先你要想好加密方案。

用户信息可是我们的敏感数据&＃xff0c;不能让别人轻易的窃取或者篡改数据了。

除了这个&＃xff0c;这个方案每次请求都要携带 COOKIE 传输&＃xff0c;这会占用外网的带宽&＃xff0c;如果 COOKIE 过大&＃xff0c;会增大网络的开销。

另外&＃xff0c;我们存储的数据大小&＃xff0c;容易受到 COOKIE 限制。

所以这种还是不怎么常用&＃xff0c;不过也是一种思路。

我比较推荐下面两种方案。

Session  粘滞&＃xff08;Sticky Sessions&＃xff09;

组长&＃xff1a;

刚才应该看到了&＃xff0c;我只是对 Nginx 的配置做了一些修改&＃xff0c;然后这个问题就解决了吧。

其实这是因为我修改 Nginx 默认的负载均衡策略&＃xff0c;使用 IP Hash 的方式。

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

架构图如下&＃xff1a;

上面这种方式我们使用 Nginx 四层负载均衡方式&＃xff0c;其实 Nginx 还可以做到七层负载均衡方式&＃xff0c;也就是使用 Http 协议中的一些业务属性来做 Hash&＃xff0c;常见的有 userId,loginId等等。

架构图如下&＃xff1a;

我&＃xff1a;

这种方案看起来挺简单的&＃xff0c;我们只需要修改 Nginx 配置就好了&＃xff0c;应用端配置无需改动。

只要请求来源 IP 足够的随机&＃xff0c;那么 IP HASH 之后两台应用上的流量将会足够随机。

另外后面如果两台机器扛不住&＃xff0c;我们还可以水平扩展&＃xff0c;再加机器&＃xff0c;只要修改 Nginx 配置即可。

组长&＃xff1a;

你说的这几点都很正确&＃xff01;

不过你有没有想过&＃xff0c;像我们公司这种情况&＃xff0c;所有人的出口的 IP 都是一个。那么我们公司的所有请求只会到一台机器上&＃xff0c;那我们这种情况等于又变成单点了。

另外如果 Tomcat 重启&＃xff0c;Session 由于是放置在内存内存中&＃xff0c;这一部分的 Session 将会丢失&＃xff0c;这就导致这部分用户将会重新登录。

最后&＃xff0c;如果我们临时再加机器&＃xff0c;修改完 Nginx 配置&＃xff0c;重新启动之后&＃xff0c;Nginx 将会重新计算 Hash 分发请求。

这种情况就会导致有一部分用户重新路由到一台新机器上&＃xff0c;由于没有 Session&＃xff0c;又需要重新登录了。

不过么&＃xff0c;Tomcat 重启或者新加机器次数不会很多&＃xff0c;所以这个问题也不大&＃xff0c;用户体验稍差点。

今天的我们这个问题解决方案就先使用这个。

不过后面我们还是改成下面这种方式。

后端集中存储

组长&＃xff1a;

上面几种的方式我们都是把 Session 存储在应用内存上&＃xff0c;应用机器只要重启&＃xff0c;Session 就会丢失。

为了这个解决这个问题&＃xff0c;我们将 Session 单独存起来&＃xff0c;保存到 Redis 或者 MySQL 中。

不过由于 Session 需要过期失效的特性&＃xff0c;不需要持久化保存&＃xff0c;所以这里我建议使用 Redis 来保存。

这样架构就变成下方这样的&＃xff1a;

我们使用这种方案&＃xff0c;上没有 Session 丢失的风险&＃xff0c;当然前提是 Redis 不能宕机。

另外后期如果应用可以直接水平扩展。

如果后面应用的请求量很大&＃xff0c;一台 Redis 扛不住了&＃xff0c;那我们可以其实可以做集群扩展&＃xff0c;根据缓存 Key 做路由。

我&＃xff1a;

对对&＃xff0c;这种方式好~

组长&＃xff1a;

你不要高兴的太早&＃xff0c;我们使用这个方案需要付出一定的代价的。

首先我们每次请求都需要调用一次 Redis &＃xff0c;这就增加一次网络的开销。

另外&＃xff0c;引入 Redis&＃xff0c;我们需要对相应的代码做出修改&＃xff0c;这样复杂度就变高。

所以说&＃xff0c;这个方案有利也有弊&＃xff0c;当然对于我们的场景来说&＃xff0c;利大于弊。

我&＃xff1a;

恩&＃xff0c;好像是这样的。

组长:

好了&＃xff0c;这么晚了&＃xff0c;问题解决了&＃xff0c;我们去撸个串&＃xff0c;我请客&＃xff01;

我&＃xff1a;

老大&＃xff0c;????&＃xff01;

组长拍了拍我的脑袋&＃xff1a;

我这一顿不是白吃哦&＃xff0c;下个星期你把现在方式修改一下&＃xff0c;修改成 Session 集中存储的方式。

给你一个小提示&＃xff0c;可以使用  spring-session。

我&＃xff1a;

好吧&＃xff0c;吃人嘴短&＃xff0c;下周我研究下。

总结

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

• Session 复制&＃xff1a;利用 Tomcat 等 Web 容器同步复制

• Session 前端存储&＃xff1a;利用用户浏览器中 COOKIE 保存 Session 信息

• Session  粘滞方案&＃xff1a;利用 Nginx 可以做四层 Hash 或七层 Hash 的特性&＃xff0c;保证用户的请求都落在同一台机器上

• Session 后端集中存储方案&＃xff1a;利用 Redis 集中存储 Session&＃xff0c;Web 应用重启或扩容&＃xff0c;Session 也无需丢失。

上面四种方案&＃xff0c;优先推荐第四种。

当然第四种方案需要一定的开发工作量&＃xff0c;前期还没改造的过程可以选择 第三种方案中间过渡。

好了&＃xff0c;后面我就要使用 Session 后端存储方案改造这个工程了&＃xff0c;后面我再跟大家分享一下 spring-session。

帮助

1. 架构师之路-session一致性架构设计实践

最后的话原创不易&＃xff0c;都看到这了&＃xff0c;点个「在看」再走呗&＃xff0c;这是对我最大的支持与鼓励&＃xff0c;谢谢你&＃xff01;往期推荐


最简单的6种防止数据重复提交的方法&＃xff01;(干货)

6种快速统计代码执行时间的方法&＃xff0c;真香!(史上最全)

关注下方二维码&＃xff0c;每一天都有干货&＃xff01;