一口气说出 4 种分布式一致性 Session 实现方式

2024-02-19 19:30

本文主要是介绍一口气说出 4 种分布式一致性 Session 实现方式,希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!

作者: 程序员通事

https://www.cnblogs.com/goodAndyxublog/archive/2020/07/17/13327412.html

 

前言

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

组长,欣赏看了一下我:

对,你这个方案确实可行。

不过么,如果用这种方案,首先你要想好加密方案。

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

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

另外,我们存储的数据大小,容易受到 Cookie 限制。

所以这种还是不怎么常用,不过也是一种思路。

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

 

Session 粘滞(Sticky Sessions)

组长:

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

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

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

架构图如下:

Session 粘滞-IP Hash

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

架构图如下:

一致性 Session-Session 粘滞-七层

小黑:

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

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

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

组长:

你说的这几点都很正确!

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

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

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

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

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

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

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

 

后端集中存储

组长:

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

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

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

这样架构就变成下方这样的:

一致性 Session-Session 后端存储

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

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

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

小黑:

对对,这种方式好~

组长:

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

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

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

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

小黑:

恩,好像是这样的。

组长:

好了,这么晚了,问题解决了,我们去撸个串,我请客!

小黑:

老大,🐂!

组长拍了拍小黑的脑袋:

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

给你一个小提示,可以使用 spring-session

小黑:

好吧,吃人嘴短,下周我研究下。

 

总结

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

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

上面四种方案,优先推荐第四种。

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

好了,后面就要使用 Session 后端存储方案改造这个工程了,后面小黑哥再跟大家分享一下 spring-session

 

 

这篇关于一口气说出 4 种分布式一致性 Session 实现方式的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!



http://www.chinasem.cn/article/725717

相关文章

hdu1043(八数码问题,广搜 + hash(实现状态压缩) )

利用康拓展开将一个排列映射成一个自然数,然后就变成了普通的广搜题。 #include<iostream>#include<algorithm>#include<string>#include<stack>#include<queue>#include<map>#include<stdio.h>#include<stdlib.h>#include<ctype.h>#inclu

【C++】_list常用方法解析及模拟实现

相信自己的力量,只要对自己始终保持信心,尽自己最大努力去完成任何事,就算事情最终结果是失败了,努力了也不留遗憾。💓💓💓 目录   ✨说在前面 🍋知识点一:什么是list? •🌰1.list的定义 •🌰2.list的基本特性 •🌰3.常用接口介绍 🍋知识点二:list常用接口 •🌰1.默认成员函数 🔥构造函数(⭐) 🔥析构函数 •🌰2.list对象

【Prometheus】PromQL向量匹配实现不同标签的向量数据进行运算

✨✨ 欢迎大家来到景天科技苑✨✨ 🎈🎈 养成好习惯,先赞后看哦~🎈🎈 🏆 作者简介:景天科技苑 🏆《头衔》:大厂架构师,华为云开发者社区专家博主,阿里云开发者社区专家博主,CSDN全栈领域优质创作者,掘金优秀博主,51CTO博客专家等。 🏆《博客》:Python全栈,前后端开发,小程序开发,人工智能,js逆向,App逆向,网络系统安全,数据分析,Django,fastapi

让树莓派智能语音助手实现定时提醒功能

最初的时候是想直接在rasa 的chatbot上实现,因为rasa本身是带有remindschedule模块的。不过经过一番折腾后,忽然发现,chatbot上实现的定时,语音助手不一定会有响应。因为,我目前语音助手的代码设置了长时间无应答会结束对话,这样一来,chatbot定时提醒的触发就不会被语音助手获悉。那怎么让语音助手也具有定时提醒功能呢? 我最后选择的方法是用threading.Time

Android实现任意版本设置默认的锁屏壁纸和桌面壁纸(两张壁纸可不一致)

客户有些需求需要设置默认壁纸和锁屏壁纸  在默认情况下 这两个壁纸是相同的  如果需要默认的锁屏壁纸和桌面壁纸不一样 需要额外修改 Android13实现 替换默认桌面壁纸: 将图片文件替换frameworks/base/core/res/res/drawable-nodpi/default_wallpaper.*  (注意不能是bmp格式) 替换默认锁屏壁纸: 将图片资源放入vendo

内核启动时减少log的方式

内核引导选项 内核引导选项大体上可以分为两类:一类与设备无关、另一类与设备有关。与设备有关的引导选项多如牛毛,需要你自己阅读内核中的相应驱动程序源码以获取其能够接受的引导选项。比如,如果你想知道可以向 AHA1542 SCSI 驱动程序传递哪些引导选项,那么就查看 drivers/scsi/aha1542.c 文件,一般在前面 100 行注释里就可以找到所接受的引导选项说明。大多数选项是通过"_

C#实战|大乐透选号器[6]:实现实时显示已选择的红蓝球数量

哈喽,你好啊,我是雷工。 关于大乐透选号器在前面已经记录了5篇笔记,这是第6篇; 接下来实现实时显示当前选中红球数量,蓝球数量; 以下为练习笔记。 01 效果演示 当选择和取消选择红球或蓝球时,在对应的位置显示实时已选择的红球、蓝球的数量; 02 标签名称 分别设置Label标签名称为:lblRedCount、lblBlueCount

Kubernetes PodSecurityPolicy:PSP能实现的5种主要安全策略

Kubernetes PodSecurityPolicy:PSP能实现的5种主要安全策略 1. 特权模式限制2. 宿主机资源隔离3. 用户和组管理4. 权限提升控制5. SELinux配置 💖The Begin💖点点关注,收藏不迷路💖 Kubernetes的PodSecurityPolicy(PSP)是一个关键的安全特性,它在Pod创建之前实施安全策略,确保P

用命令行的方式启动.netcore webapi

用命令行的方式启动.netcore web项目 进入指定的项目文件夹,比如我发布后的代码放在下面文件夹中 在此地址栏中输入“cmd”,打开命令提示符,进入到发布代码目录 命令行启动.netcore项目的命令为:  dotnet 项目启动文件.dll --urls="http://*:对外端口" --ip="本机ip" --port=项目内部端口 例: dotnet Imagine.M

工厂ERP管理系统实现源码(JAVA)

工厂进销存管理系统是一个集采购管理、仓库管理、生产管理和销售管理于一体的综合解决方案。该系统旨在帮助企业优化流程、提高效率、降低成本,并实时掌握各环节的运营状况。 在采购管理方面,系统能够处理采购订单、供应商管理和采购入库等流程,确保采购过程的透明和高效。仓库管理方面,实现库存的精准管理,包括入库、出库、盘点等操作,确保库存数据的准确性和实时性。 生产管理模块则涵盖了生产计划制定、物料需求计划、