2. 令牌刷新接口的业务流程与性能指标定义
在认证授权平台中，令牌刷新接口（Token Refresh）是用户无感续期会话的核心入口。与登录接口不同，刷新接口的调用频率更高、对延迟更敏感，且必须保证极高的成功率，否则将直接导致用户被迫重新登录，严重影响用户体验。本节将拆解其完整业务流程，并定义调优所依赖的关键性能指标。
2.1 令牌刷新接口的完整业务流程
一次标准的令牌刷新请求，从客户端发起至响应返回，通常经历以下 6 个核心步骤。其中，步骤 3 和步骤 5 是 Redis 缓存介入的关键环节。
核心流程说明： 刷新令牌（Refresh Token）通常为长期有效（如 7 天），而访问令牌（Access Token）为短期有效（如 15 分钟）。刷新接口的核心职责是验证 Refresh Token 有效性，并签发新的 Access Token 和 Refresh Token。
2.2 性能指标定义
为了量化调优效果，必须建立统一的性能指标体系。针对令牌刷新接口，我们重点关注以下三个核心指标：QPS（每秒查询数）、延迟（Latency） 和 成功率（Success Rate）。
| 指标名称 | 定义 | 测量方式 | 典型目标值 |
|---|---|---|---|
| QPS | 接口在 1 秒内成功处理的请求数量 | Prometheus + Grafana 实时监控 | ≥ 10,000（单节点） |
| P99 延迟 | 99% 的请求在多少毫秒内完成 | APM 工具（如 SkyWalking）采样 | ≤ 50 ms |
| P50 延迟 | 50% 的请求在多少毫秒内完成（中位数） | APM 工具采样 | ≤ 15 ms |
| 成功率 | 返回 HTTP 2xx 的请求数 / 总请求数 | 日志聚合 + 健康检查 | ≥ 99.99% |
调优优先级建议： 在缓存策略优化中，通常优先保证成功率（避免缓存击穿导致数据库崩溃），其次优化 P99 延迟（提升用户体验），最后追求 QPS 提升（降低硬件成本）。切勿为了 QPS 而牺牲数据一致性。
2.3 延迟分解与瓶颈定位
为了更精确地定位性能瓶颈，需要将接口总延迟拆解为以下四个子阶段。每个子阶段都有对应的优化空间。
2.4 成功率的关键影响因素
成功率并非单纯由代码健壮性决定，缓存策略的失误往往是导致刷新接口失败的主要原因。以下是三种典型的缓存相关失败场景：
- 缓存击穿： 某个热点 Refresh Token 在过期瞬间，大量并发请求同时穿透到数据库，导致数据库连接池耗尽，请求超时失败。
- 缓存雪崩： 大量 Refresh Token 在同一时间窗口过期（如设置相同的 TTL），导致 Redis 瞬间负载飙升，部分请求被拒绝。
- 数据不一致： 由于 Redis 主从同步延迟，客户端刷新后立即使用新令牌，但从节点尚未同步，导致验证失败。
重要提醒： 在定义性能指标时，务必同时建立 错误码分类 机制。例如：将 500 错误细分为“缓存超时”、“数据库超时”、“令牌校验失败”等子类。只有精确分类，才能指导后续的缓存策略优化方向。
2.5 指标采集与监控方案
为了在调优过程中实时观察指标变化，建议采用以下技术栈进行数据采集：
| 组件 | 作用 | 采集指标 |
|---|---|---|
| Prometheus | 时序数据库，存储指标数据 | QPS、延迟分布、错误计数 |
| Grafana | 可视化仪表盘 | 实时曲线、P99/P50 延迟图 |
| Redis INFO | Redis 内部状态 | 命中率、内存使用、慢查询 |
| APM（SkyWalking） | 分布式链路追踪 | 各阶段耗时、调用链拓扑 |