一、 背景：一个 Token 的两难境地
在微服务或前后端分离架构中，Access Token 是用户身份的唯一凭证。关于它的存储，我们面临两个看似矛盾的需求：
- 极速验证：每个接口请求（QPS 可能高达数万）都要验证 Token，延迟必须在毫秒级。
- 数据安全与管理：Token 关系到用户安全，不能丢；管理员需要在后台查询、踢人下线，需要复杂的查询能力。
解决方案： 采用 "Redis (热数据) + MySQL (冷数据)" 的双存储架构。
二、 核心问题 1：后端鉴权时，该读 Redis 还是 MySQL？
结论：只读 Redis，绝不读 MySQL。
当用户发起请求 GET /order/list 并携带 Bearer Token 时，后端的拦截器（Filter）执行流程如下：
-
Redis 是"地铁闸机"：
- 拦截器直接去 Redis 查询该 Token。
- 有数据 ：放行。耗时 < 1ms。
- 无数据 ：直接拦截，返回
401 Unauthorized。不进行 MySQL 回源查询。
-
MySQL 是"户籍档案室"：
- MySQL 的作用不是用来给代码做实时鉴权的。
- 如果每个请求都查 MySQL，数据库连接池瞬间就会被耗尽，整个系统会因为鉴权逻辑而崩溃。
原则： 在高频的鉴权场景下，Redis 是唯一的 "权威（Authority）"。
三、 核心问题 2：Redis 和 MySQL 的一致性如何保持？
既然两边都存了，如何保证数据不打架？我们按 Token 的生命周期分为四个阶段来看：
1. 登录阶段（创建：双写）
当用户登录成功生成 Token 时：
- 动作 A ：将 Token 信息插入 MySQL（作为持久化备份，供管理员查询）。
- 动作 B ：将 Token 信息写入 Redis ，并设置 TTL (过期时间)（如 30 分钟）。
- 一致性评价：强一致。
2. 鉴权阶段（读取：Redis 主导）
- 动作：只读 Redis。
- 异常情况：如果 Redis 数据丢了（如宕机）但 MySQL 还在，怎么办？
- 策略 ：认栽。系统视作用户"未登录"，前端会触发刷新 Token 或重新登录流程。绝不回源查 DB，防止缓存击穿导致数据库雪崩。
3. 过期阶段（自然消亡：最终不一致）
- 动作 ：
- Redis：TTL 一到，自动删除 Key。用户访问报 401。
- MySQL：数据依然存在，变成了"历史垃圾数据"。
- 策略 ：允许不一致。这种不一致对业务无害（因为鉴权只看 Redis），MySQL 的历史数据可以通过定时任务清理。
4. 登出/踢人阶段（销毁：双删）
这是最关键的一步，必须保证安全。
- 动作 ：显式删除 MySQL + 显式删除 Redis。
- 顺序建议 ：
删 DB->删 Redis（符合 Cache Aside Pattern）。 - 策略：必须确保 Redis 被删掉，否则用户在 Token 过期前还能非法访问。