分布式SESSION一致性
分布式SESSION一致性
SESSION
是服务器为客户端创建的一个会话,存储用户的相关信息,用以标识用户身份等。在单服务器环境下是不需要考虑会话的一致性的问题的,但是在集群环境下就会出现一些问题,假如一个用户在登录请求时负载均衡到了A
服务器,A
服务器为其分配了SESSION
,下次请求数据时被分配到了B
服务器,此时由于B
服务器不存在此用户的SESSION
,此用户会被重定向到登录页面,这种情况是不合理的业务逻辑,所以需要维护SESSION
的一致性。
解决方案#
SESSION 同步#
多个服务器之间互相同步SESSION
,即A
服务器生成一个SESSION
信息后同步传输到B
、C
、D
等服务器,同样B
、C
、D
服务器生成SESSION
信息后也需要同步到A
,这样每个服务器之间都包含全部的SESSION
优点#
- 大部分应用服务器都提供了
SESSION
复制的功能来实现集群
缺点#
SESSION
需要网络传输进行同步,其会占用带宽,并且存在一定的延迟- 一旦某台机器的
SESSION
信息有所变化,必须同步更新所有服务器SESSION
内容 - 每个服务器都会存储全部的用户信息,性能随着服务器增加急剧下降,而且容易引起广播风暴
SESSION 映射#
通过将负载均衡服务器进行修改,通过对返回给用户的SESSION ID
或者用户请求的IP
地址进行标记,也就是使用第四层传输层中读取网络层的IP
或者是在第七层中读取HTTP
协议中某些属性来做HASH
,保证对于此用户的请求全部落到同一台服务器上
优点#
- 实现相对简单
- 只要分配服务器时均匀,则多台服务器是负载均衡的
缺点#
- 一旦某台服务器宕机,则会影响落在此服务器请求上的全部用户
- 负载均衡服务器变为了一个有状态的节点,内存消耗会更大,容灾更麻烦
客户端存储#
将数据直接存储到客户端比如Cookie
或请求头中,每次请求客户端自动携带数据信息
优点#
- 简单,高效
- 服务端不需要储存标记用户信息
缺点#
- 安全性较差,对于敏感信息必须加密
- 每次请求可能携带大量数据,占用外网带宽
- 数据存储在客户端就会存在泄密、篡改、窃取等隐患
后端集中存储#
将SESSION
存储在一台单独的服务器中的数据库中,例如Mysql
、Oracle
、SqlServer
、Redis
、Mongodb
等等,各SERVER
服务器需要用户信息时携带SESSION ID
对于集中存储服务器进行请求,进而获取用户信息
优点#
- 没有安全隐患
- 可以方便的水平拓展
SERVER
服务器重启不会造成SESSION
丢失
缺点#
- 每次请求都增加了一次对于存储服务器的网络请求
- 会对集中存储服务器存在大量请求,数据库压力比较大
每日一题#
https://github.com/WindrunnerMax/EveryDay
参考#
https://www.jianshu.com/p/5caed857dc3e
https://www.cnblogs.com/study-everyday/p/7853145.html
【推荐】国内首个AI IDE,深度理解中文开发场景,立即下载体验Trae
【推荐】编程新体验,更懂你的AI,立即体验豆包MarsCode编程助手
【推荐】抖音旗下AI助手豆包,你的智能百科全书,全免费不限次数
【推荐】轻量又高性能的 SSH 工具 IShell:AI 加持,快人一步
· 基于Microsoft.Extensions.AI核心库实现RAG应用
· Linux系列:如何用heaptrack跟踪.NET程序的非托管内存泄露
· 开发者必知的日志记录最佳实践
· SQL Server 2025 AI相关能力初探
· Linux系列:如何用 C#调用 C方法造成内存泄露
· 终于写完轮子一部分:tcp代理 了,记录一下
· 震惊!C++程序真的从main开始吗?99%的程序员都答错了
· 别再用vector<bool>了!Google高级工程师:这可能是STL最大的设计失误
· 单元测试从入门到精通
· 【硬核科普】Trae如何「偷看」你的代码?零基础破解AI编程运行原理