3. 缓存架构设计

在认证授权平台中，缓存是支撑高并发令牌校验与刷新的核心基础设施。OIDC 协议要求客户端定期刷新令牌（Refresh Token），而每次刷新都涉及对用户会话、授权范围、客户端元数据的查询。若每次刷新都穿透到数据库，平台将无法承受大规模并发。本章从缓存层次、键设计原则、失效策略三个维度，构建一个高可用、低延迟的缓存架构。

3.1 缓存层次：本地缓存与分布式缓存

认证授权平台通常采用两级缓存架构：本地缓存（L1） 与 分布式缓存（L2）。两者在延迟、容量、一致性上各有取舍，需根据令牌校验路径的读写特征进行分层部署。

3.2 缓存键设计原则

缓存键（Cache Key）的设计直接影响命中率、冲突概率和运维可读性。在认证授权平台中，键设计需遵循以下原则：

1. 唯一性：键必须能唯一标识一个缓存条目，避免不同数据共享同一键导致脏读。
2. 可读性：键应包含业务语义，便于在 Redis 控制台或日志中快速定位问题。
3. 避免热点：避免使用固定前缀 + 自增 ID 的简单模式，防止 Redis 分片倾斜。
4. 版本化：在键中嵌入数据版本号或 schema 版本，支持平滑迁移。
5. TTL 友好：键结构应支持按业务维度批量失效（如按用户 ID 前缀扫描）。

3.3 缓存失效策略

缓存失效是认证授权平台中最容易引发故障的环节。失效策略选择不当会导致：用户明明已登出，但令牌仍被缓存视为有效（缓存穿透）；或缓存频繁失效导致数据库压力激增（缓存雪崩）。以下是三种核心失效策略及其适用场景：

3.3.1 基于 TTL 的被动失效

为每个缓存条目设置过期时间（TTL），到期后自动删除。这是最基础、最可靠的策略，适用于所有缓存对象。关键点在于 TTL 的设置必须小于或等于后端数据的实际有效期。

// 设置 Refresh Token 缓存，TTL 等于令牌剩余有效期
String key = "oidc:session:" + sub + ":" + tokenId;
int ttlSeconds = refreshToken.getExpiresIn(); // 例如 3600 秒
redisTemplate.opsForValue().set(key, sessionData, ttlSeconds, TimeUnit.SECONDS);

3.3.2 基于事件的主动失效

当用户执行登出、密码修改、权限变更等操作时，由业务系统主动发送失效事件，清除相关缓存。这是保证缓存与数据库一致性的关键手段。

• 本地缓存失效：通过消息队列（如 RabbitMQ、Kafka）广播失效事件，各节点监听后清除本地缓存。
• 分布式缓存失效：直接调用 Redis 的 DEL 命令删除指定键，或使用 EXPIRE 命令立即过期。

// 用户登出时主动失效所有相关缓存
public void invalidateUserSession(String sub) {
    // 1. 失效分布式缓存中的会话
    String pattern = "oidc:session:" + sub + ":*";
    Set<String> keys = redisTemplate.keys(pattern);
    if (keys != null && !keys.isEmpty()) {
        redisTemplate.delete(keys);
    }
    // 2. 发送广播事件，通知各节点失效本地缓存
    eventPublisher.publishEvent(new SessionInvalidationEvent(sub));
}

3.3.3 预热与防雪崩策略

在缓存大规模失效（如重启、TTL 集中到期）时，需要防止所有请求同时穿透到数据库。常用手段包括：

• 加随机 TTL：在基础 TTL 上增加 ±10% 的随机偏移，避免大量键同时过期。
• 本地缓存兜底：即使分布式缓存失效，本地缓存仍能提供短时间的数据服务。
• 限流与熔断：对数据库查询接口实施限流，防止缓存雪崩击穿数据库。

3.4 缓存架构设计检查清单