【成为架构师3-18】缓存：并发更新造成token相互失效的问题

最新推荐文章于 2024-11-02 16:14:10 发布
最新推荐文章于 2024-11-02 16:14:10 发布
阅读量781 收藏 2
点赞数
CC 4.0 BY-SA版权
分类专栏： 成为架构师 文章标签： 缓存
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.youkuaiyun.com/Sunsscode/article/details/108929990
本文介绍了在只有缓存无数据库的业务场景下，如微信access_token的获取，如何处理并发更新引发的token递归失效问题。当多个请求并发发现token过期并尝试更新时，会导致无限递归申请新token。为解决这个问题，提出了将token申请独立为专门的服务，并采用影子主技术确保高可用，虽然这增加了读写服务与缓存的耦合，但在这种特定业务场景中，这是个合理的设计选择。

摘要生成于 C知道 ，由 DeepSeek-R1 满血版支持， 前往体验 >

系列文章是博主对沈剑的《架构师训练营》分享内容的个人笔记总结，原内容公众号“成为架构师”。

目录

业务场景引入

前面讲的都是缓存和数据库在一起的情况，但有时候部分业务场景是只有缓存而没有数据库的，比如说微信的access_token获取的场景：

  1. 微信对调用方都需求一个access_token，只有携带这个token，才能调用接口
  2. token是具有有效期的（微信的7200s，两小时），如果token失效，那么调用方应该重新去申请token
  3. 也可以在token过期前主动申请，但是只有当前token有效，上一个token会失效
并发更新造成递归申请

如果请求发现缓存里的token过期了，那么它去申请新的token，再把这个token写回缓存，并用此token去进行接口调用。

现在来考虑一种极端情况：

假设有A，B两个请求，A发现token过期了，那么它就去申请token，这里命名为token1，在这个时间内，B自然也发现token过期了，B也去申请token，这里是token2，A获得token1之后把token1写回缓存，再用token1去调用接口，此时就会发现token1也提示过期了，那么它就会再去申请token3。

对于B来说，它申请完token2，把token2写入缓存，用token2去调用接口，发现token2过期了（因为A这个时候申请了token3），它就再去申请token4。
在这里插入图片描述
这样子上述过程就陷入了递归调用之中，从外部来看就是不停地申请token，不停地失效这样子的诡异情况。

解决方案

递

最低0.47元/天 解锁文章

200万优质内容无限畅学
【成为架构师3-17】缓存：数据一致性优化二次淘汰法
Nevercome
10-03 735
数据冗余必然引发一致性问题，而数据库与缓存的不一致性问题可能会造成缓存内长时间为旧数据，针对这一情况我们通常有二次淘汰和设置超时时间两种解决方法。
【成为架构师3-20】章节小结：千万流量，这些技术就够了：服务化、数据库、缓存
Nevercome
10-11 401
千万流量篇技术总结：服务化、数据库、缓存
并发的情况下，如何刷新token失效问题
weixin_42845571的博客
06-01 2644
什么事并发情况下token失效：进入同一个页面，会有同时多个接口都在调用，接口调用都是异步请求，而这时候token是失效的，导致这些接口调用都是因为token失效问题，又不能因为某个接口token失效而改变token之后才去调用其他接口，因为接口现在调用都是异步的，除非自己写成同步。 方法： 1.利用 Redis 缓存:后端在用户第一次登录时，需要将生成的 Token 数据,缓存一份到 Redis 中.当 Token 过期时，重新生成新的 Token 数据并更新 Redis 缓存，同时在 Redis 中设置
微信获取token解决并发问题
weixin_42609225的博客
02-09 567
微信的 token 是用来识别请求者身份的，因此在处理并发请求时需要特别注意。解决并发问题的方法可以采用以下几种： 加锁：在多个请求同时对 token 进行请求的情况下，使用锁的机制，只允许一个请求同时进行 token 的获取操作。 缓存：在微信获取的 token 有效期内，将它缓存在服务器上，避免每次请求都向微信请求 token。 限流：设置请求频率限制，在每个时间段内最多允许请求一定数量...
token刷新问题
qq_54951190的博客
10-24 2318
双拦截器实现token刷新问题
Redis-高并发下缓存失效问题
一位打工仔的博客
12-25 557
指查询一个一定不存在的数据，由于缓存是不命中，将去查询数据库，但是 数据库也无此记录，我们没有将这次查询的null写入缓存，这将导致这个不 存在的数据每次请求都要到存储层去查询，失去了缓存的意义。缓存雪崩是指在我们设置缓存时key采用了相同的过期时间，导致缓存在某一时刻同时失效，请求全部转发到DB，DB瞬时压力过重雪崩。大量并发只让一个去查，其他人等待，查到以后释放锁，其他 人获取到锁，先查缓存，就会有数据，不用去db。风险： 利用不存在的数据进行攻击，数据库瞬时压力增大，最终导致崩溃。
微信小程序存储token在本地缓存不一致的情况
lmy1329160579的博客
06-03 1926
今天遇到个问题，客户反馈问题后，我们开发实在无法复现，开发手机都是流程没问题的。场景如下： 我们服务端采用了token，用户登录成功后就会下发一个token，假如原token没过期，我们则会刷新token，即覆盖操作。从日志上看，用户的操作流程如下： 用户登录后，拿到A token，然后开始用这个token进行调用接口，一切正常。 而后，用户又进行了一次小程序登录，我们下发了新token，B Token给到前端，用户拿B token也请求了一段时间，然后用户录制一个视频过来，显示点击每一个接口都是报错的，用
高并发电商系统-Java并发编程-Redis缓存优化-MySQL存储过程-行级锁优化-CDN动静分离-前端防重复提交-商品秒杀系统-事务竞争优化-热点数据预加载-分布式系统设计-微.zip
最新发布
07-19
系统架构师需要根据业务特点和访问模式，综合运用Java并发编程、缓存优化、数据库锁策略、内容分发网络、前端防重复提交、商品秒杀策略、事务竞争优化、热点数据预加载以及分布式系统设计等多种技术，来打造一个既...
从容错到限流：保障微服务可靠性的关键策略分析
热门推荐
张彦峰的博客
02-07 168万+
本文探讨了微服务架构中常见的容错与故障应对机制，包括限流、降级和熔断。通过对这些机制的原理、应用场景和实现方法的详细分析，本文旨在帮助读者理解如何在高并发和故障环境中确保系统的稳定性与高可用性。文章强调了合理设计和灵活应用容错策略对提升系统可靠性的重要性，同时也展望了随着微服务架构发展，容错机制的未来方向。
关于token的总结和思考——并发访问刷新策略，jwt过期及作废问题
scau_cdx的博客
08-01 7605
前言： 最近在尝试做前后端分离的项目，由于之前一直听过token和jwt，似乎在前后端分离中也很常用。于是便了解了一番，结果扯出一大堆问题，折腾了好久，所以想把一些问题和思考记录一下。另外，其实前后端分离若无特殊需求，也不必执着于使用token认证，毕竟这会引发一些问题，未必就比传统cookie-session好。下面逐步讲述。 token刷新策略 传统的token认证，...
token刷新并发 java_retrofit 刷新token并发处理
weixin_34369657的博客
02-27 1042
情况说明在app开发中，我们需要保证用户登录之后，如果没有在其他设备上登录，则不需要再次登录，很多都会使用token作为安全令牌，开始阶段都会在登录时候获取，一直使用到下次登录。这样的token没有什么安全性可言，所以大多app都会做token时效性处理。刷新token流程图如下：刷新token流程图.png暂时我了解的方案有两种：在获取token的时候，同时获得token的有效时间和刷新toke...
Token 刷新并发处理解决方案
Star's Tech Blog
12-03 5054
对 Token 进行刷新续期，我们要解决并发请求导致重复刷新 Token 的问题，这也是设计刷新 Token 的难点。这里我会分别介绍前端和后端各自的处理方案。 后端方案：利用 Redis 缓存 当同时发起多个请求时，第一个接口刷新了 Token，后面的请求仍然能通过请求，且不造成 Token 重复刷新。那么，后端在用户第一次登录时，需要将生成的 Token 数据（token 和 createTime）缓存一份到 Redis 中。 当 Token 过期时，重新生成新的 Token 数据并更新 Redis 缓
token无感刷新+处理并发的后端方案
m0_64106946的博客
11-02 1530
当用户通过登陆后进入一个web网站，会把token保存到localStorage。假设token过期时间30min。那么当用户在网站快乐地玩耍了30min后，这时进行了一次提交表单，它会被重定向到登陆页面。作为用户：我表单填了这么久，点击提交时让我重新登陆？我的体验很不好。
解决Shiro jwt并发刷新token问题
大爱仙尊
05-02 2万+
使用shiro jwt做应用系统的权限校验，网上通用的方式是这样的。 在用户登录时候会生成两份token，一份AccessToken用于返回给前端，前端带上这个令牌去请求后台接口，通常过期时间较短5分钟左右，一份RefreshToken放在Redis中，两个Token的加密值都是当前时间戳，当用户的AccessToken过期时，就去从Redis中通过用户名取得Redis中的RefreshToken，比较AccessToken和RefreshToken中的时间戳是否一致，如果一致就重新生成一...
解决并发请求下刷新多个token的问题
qq_42274445的博客
05-21 1867
使用redis加锁实现，拿到锁的线程进行token刷新，拿不到锁的线程跳过token刷新 具体实现 /** * 刷新AccessToken */ private boolean refreshToken(String uid,String account, ServletResponse response) { Boolean lock = JedisUtil.getLock(account);//获取锁 if(lock){
redis使用—缓存在高并发下的问题及分布式锁
qq_38151401的博客
01-09 1018
目录 一、redis整合过程 1 引入pom依赖信息(本工程所有redis统一放入service-util) 2 写一个reids的工具类(用来将redis的池初始化到spring容器中) 3 写一个spring整合redis的配置类 4 注意：每个以用工程引入service-util后，单独配置自己的redis的配置文件 5、使用：通过缓存查询的代码测试 6、在高并发环境下还有如下...
微服务token错误失效
m1s2q3l4的博客
11-30 1813
问题无法获取小程序二维码？ 我的问题：wxAccessToken接口用于token刷新，40分钟一次没有问题，但是如果项目关闭40分钟以上，定时任务就废掉了，两种解决方式 还有其他方式请大佬们留言学习学习，谢谢 1，主动调用那个借口刷新借口 2、等待40分钟，等待定时任务自己执 自己定义的token是直接在微信官网中获取token 获取图片的接口，其中加了流。微信小程序 唯一标识，和秘钥在自己的公司开发公众号平台上查看 获取token 工具类 package com.zfbgt
Token高并发解决方案
过去过去，未来未来，当下永恒！
01-05 2905
Token高并发解决方案 一：作为token使用的第三方 客户端模式使用token 可以采用单例模式或定义一个全局变量isRefresh 标志，加同步锁Synchronized来保证token过期的那个时间点，刷新token方法只被调用一次。 二：作为token服务器端： 后端方案：利用 Redis 缓存 当同时发起多个请求时，第一个接口刷新了 Token，后面的请求仍然能通过请求，且不造成 Token 重复刷新。那么，后端在用户第一次登录时，需要将生成的 Token 数据（token 和 createTi
解决token冲突
luanluan8888的博客
02-13 1864
当在项目中多个模块都生成token时，缓存中的token可以保证在同一个时空内不重复(因为uuid不会重复。token = uuid.uuid4().hex）但是cache中的KEY是有可能重复的，因为id都是从1开始的。例如：同一个项目中，有后管理用户和影院用户，其user_id都是从1开始的生成,当user_id = cathe.get(token)时，有可能可以用影院用户的token执行后台...
单点登录sso遇到的问题
03-13
<think>好的，我现在需要帮助用户解答关于单点登录（SSO）遇到的问题。首先，我需要回想一下用户之前的问题，他们之前询问了RocketMQ的负载均衡机制，现在转向了SSO的问题。这说明用户可能在系统设计和架构方面有一些深入的考虑，可能是在构建或维护一个分布式系统，需要处理多个服务的身份验证问题。 用户的问题是关于SSO遇到的问题，我需要先明确SSO的基本概念，然后分析常见的问题和挑战。单点登录允许用户在一个系统中登录后，无需再次登录即可访问其他关联系统，这在企业应用和微服务架构中非常常见。接下来，我需要列举SSO实施过程中可能遇到的各种问题，并解释其原因和解决方案。 首先，跨域认证的问题。由于现代应用通常部署在不同的域名下，浏览器的同源策略会限制Cookie的共享。这时候需要用到跨域认证机制，比如OAuth、SAML或者设置顶级域名Cookie。但用户可能不清楚这些技术的具体实现方式，需要给出具体的例子，比如如何设置Cookie的domain属性。 然后是信任域配置的复杂性。不同的系统可能属于不同的信任域，需要建立信任关系。例如，使用SAML时需要配置IDP和SP的元数据，证书管理也是一个挑战。这里需要提到证书过期或配置错误可能导致单点登录失败，建议自动化的证书轮换和配置校验工具。 安全性方面，令牌泄露和重放攻击是常见问题。攻击者可能截获令牌并冒充用户，所以必须使用HTTPS来加密传输，同时设置短的有效期和刷新机制。此外，单点登录的集中性意味着一旦认证中心故障，所有依赖的系统都无法登录，所以需要设计高可用和容灾方案，比如集群部署和健康检查。 用户体验方面，不同系统的登出机制可能不一致，导致用户退出一个系统后，其他系统仍处于登录状态。这就需要实现全局登出，比如通过中央认证中心广播登出请求，或者使用前端重定向确保所有系统的会话失效。 协议兼容性也是一个问题，尤其是旧系统可能不支持现代协议如OAuth 2.0，这时候需要中间件或适配层进行协议转换。例如，为遗留系统开发一个SAML到传统认证的网关。 性能方面，集中认证可能成为瓶颈，特别是在高并发场景下。需要引入缓存机制，如Redis存储会话信息，以及负载均衡来分散请求压力。此外，令牌的验证过程应尽量高效，减少延迟。 还有用户信息同步的问题，比如用户在中心系统修改资料后，如何同步到其他子系统。可以通过事件驱动架构，比如消息队列通知各系统更新数据，或者提供统一的用户信息查询接口。 在思考过程中，我需要确保覆盖所有主要问题，并提供具体的解决方案和最佳实践。同时，要避免过于技术化的术语，让不同层次的读者都能理解。可能用户是开发人员或架构师，需要详细的技术细节，比如代码示例或配置建议，但也要保持解释的清晰性。 最后，总结部分需要强调SSO的优势与挑战，并提醒根据实际需求选择合适的技术方案，同时注意安全性和可维护性。可能用户在实际实施中遇到的具体问题没有完全列出，因此建议部分应包含监控、日志分析和定期审计的重要性，以应对未预见的问题。</think>以下是关于单点登录（SSO）实现中常见问题的系统化分析，涵盖**技术挑战**、**安全风险**和**解决方案**： --- ### **一、核心挑战** #### **1. 跨域认证问题** - **问题描述**： 浏览器同源策略（Same-Origin Policy）限制Cookie跨域共享，导致不同域名下的系统无法直接传递登录态。 - **典型案例**： 主站`www.a.com`登录后，子系统`app.b.com`无法自动获取用户凭证。 - **解决方案**： - **跨域认证协议**：使用OAuth 2.0、SAML或OpenID Connect，通过令牌（Token）传递认证信息。 - **共享顶级域名Cookie**：将认证中心域名设为父域（如`.example.com`），所有子域共享Cookie。 ```nginx # Nginx配置Cookie作用域为父域 add_header Set-Cookie "session_id=xxx; Domain=.example.com; Path=/"; ``` #### **2. 信任域配置复杂性** - **问题描述**： 各子系统需与认证中心（IDP）建立信任关系，涉及证书、密钥、元数据等复杂配置。 - **常见错误**： - SAML的SP（服务提供方）与IDP（身份提供方）元数据不一致。 - 证书过期导致令牌验签失败。 - **解决方案**： - **自动化配置工具**：使用Keycloak、Okta等SSO平台自动同步信任配置。 - **证书轮换机制**：定期更新证书并兼容新旧证书共存期。 --- ### **二、安全风险** #### **1. 令牌泄露与劫持** - **风险场景**： - 令牌通过URL传递（如OAuth的Implicit模式）可能被浏览器历史记录或日志泄露。 - 中间人攻击（MITM）截取未加密的令牌。 - **防护措施**： - **强制HTTPS**：所有SSO交互链路加密。 - **短期令牌**：设置短有效期（如JWT的`exp`字段），结合刷新令牌（Refresh Token）机制。 - **令牌绑定**：将令牌与客户端IP或设备指纹绑定。 #### **2. 单点失效风险** - **风险场景**： 认证中心（如Keycloak）宕机时，所有依赖系统无法登录。 - **容灾方案**： - **多活部署**：认证中心集群化，通过负载均衡（如Nginx）分散请求。 - **本地缓存降级**：在子系统中缓存最近的有效令牌（需权衡安全性）。 --- ### **三、协议与实现问题** #### **1. 协议兼容性冲突** - **问题现象**： 不同系统支持的SSO协议不一致（如旧系统仅支持CAS，新系统需用OAuth 2.0）。 - **解决方案**： - **协议网关**：部署适配层（如Pac4j）实现协议转换。 - **多协议支持**：认证中心同时兼容SAML、OAuth、LDAP等。 #### **2. 全局登出（Single Logout）难题** - **问题描述**： 用户退出一个系统时，需同步注销所有关联系统的会话。 - **实现方案**： - **反向通道通知**：认证中心主动调用子系统的登出接口。 - **前端重定向链**：依次跳转各子系统登出URL（依赖浏览器重定向）。 ```http // 登出流程示例 GET /sso/logout?redirect=https://app1.com/logout&then=https://app2.com/logout ``` --- ### **四、用户体验问题** #### **1. 多系统权限差异** - **问题场景**： 用户登录后，部分系统提示权限不足，需重新登录或申请授权。 - **优化方案**： - **统一权限中心**：在SSO基础上集成RBAC（角色权限模型），同步权限数据。 - **动态授权**：通过OAuth的Scope机制按需申请权限。 #### **2. 首次登录跳转混乱** - **问题现象**： 用户直接访问子系统时，多次重定向导致URL参数丢失或页面白屏。 - **调试方法**： - **标准化流程**：遵循OAuth的Authorization Code Flow。 - **Session状态跟踪**：使用`state`参数防止CSRF，并记录跳转来源。 --- ### **五、性能与扩展性问题** #### **1. 高并发下的性能瓶颈** - **压力点**： 认证中心的令牌签发、验签、会话查询可能成为性能瓶颈。 - **优化策略**： - **分布式会话存储**：使用Redis集群缓存用户会话。 - **JWT无状态令牌**：通过签名自包含用户信息，减少中心化验签开销。 ```java // JWT生成示例（使用JJWT库） String jwt = Jwts.builder() .setSubject("user123") .signWith(SignatureAlgorithm.HS256, "secret-key") .compact(); ``` #### **2. 用户属性同步延迟** - **问题场景**： 用户在认证中心修改个人信息后，子系统未及时更新。 - **解决方案**： - **事件驱动同步**：通过消息队列（如Kafka）广播用户信息变更事件。 - **主动查询接口**：子系统调用认证中心的`/userinfo`端点获取最新数据。 --- ### **六、总结与建议** | **问题类型** | **关键挑战** | **推荐方案** | |--------------------|-----------------------------|-----------------------------------------| | 跨域认证 | 同源策略限制 | OAuth 2.0 + 顶级域名Cookie | | 安全风险 | 令牌泄露、MITM攻击 | HTTPS + 短期令牌 + IP绑定 | | 协议兼容性 | 新旧系统协议冲突 | 协议网关（如Pac4j） | | 性能瓶颈 | 高并发验签压力 | JWT无状态令牌 + Redis集群 | | 用户体验 | 权限不一致、登出不全 | RBAC集成 + 反向通道注销 | **实施建议**： 1. **协议选择**：优先使用OAuth 2.0/OpenID Connect（现代应用）或SAML（企业级集成）。 2. **安全加固**：定期审计令牌生命周期管理，监控异常登录行为。 3. **容灾设计**：认证中心多活部署，子系统支持本地会话降级。 4. **监控指标**：跟踪SSO成功率、平均登录耗时、令牌失效异常率。
评论 1
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值