1. 缓存失效的基本模型
1.1 缓存失效的定义
缓存失效是指在缓存系统中使已存储的数据副本变为无效、过期或不可用的操作。作为缓存与持久化存储之间的核心边界控制点，失效确定了数据在缓存层中的生命周期终点。
从架构分层职责看，缓存层负责加速读访问，持久化层保证完整性与一致性，而失效机制则充当二者之间的控制流闸门。
核心概念：失效不是删除数据，而是标记或移除缓存中“不再可信”的副本，触发后续的数据重新加载或穿透。
1.2 常见触发条件
| 触发条件 | 描述 | 典型场景 |
|---|---|---|
| TTL 超时 | 缓存项设置了生存时间，到期自动失效 | 用户会话、临时验证码 |
| 主动失效 | 业务代码显式调用失效接口 | 更新商品信息后删除对应缓存键 |
| 容量淘汰 | 缓存空间不足时按策略淘汰 | LRU/LFU 淘汰最近最少使用项 |
| 数据源变更 | 数据库或上游服务发生写操作 | 订单状态变更、库存变化 |
| 版本不匹配 | 缓存数据版本落后于持久化版本 | 分布式场景下的版本号比对 |
1.3 失效后的数据流
失效发生后，数据流遵循“缓存未命中 → 回源加载 → 更新缓存 → 返回响应”的基本路径。下图展示了典型的失效后数据流与分层职责。
1.4 失效后的数据流步骤
- 客户端发起读请求：携带缓存键（如
user:1234:profile）。 - 缓存层检查：根据 TTL / 状态判断该键是否有效。若命中且未过期，直接返回缓存副本（结束）。
- 触发失效行为：若过期、被淘汰或主动失效，标记为不可用，将请求穿透到数据源。
- 数据源回源：从持久化层（MySQL / DynamoDB / 上游服务）获取最新完整数据。
- 更新缓存：将新数据写入缓存层，并重置 TTL 或版本号。
- 响应客户端：返回最新数据，后续相同请求将从缓存中直接获得。
1.5 风险点与策略权衡
| 风险点 | 说明 | 典型应对策略 |
|---|---|---|
| 缓存穿透 | 大量请求访问不存在的数据，绕开缓存直击数据库 | 布隆过滤器 / 空值缓存 |
| 缓存击穿 | 热点数据失效瞬间，大量请求并发回源 | 互斥锁 / 预加载 / 永不过期+异步更新 |
| 缓存雪崩 | 大量缓存同时失效，引发数据库负载飙高 | TTL 随机化 / 多级缓存 / 限流 |
| 数据不一致 | 失效后回源竞争导致旧数据被重新缓存 | 版本号 / CAS 写 / 消息队列顺序更新 |
1.6 落地步骤与验收标准
落地步骤：
- 定义缓存键命名规范与 TTL 范围（如 5~30 分钟）。
- 代码中封装统一的失效接口（
del(key)/expire(key, ttl)）。 - 对每个数据源变更操作，同步触发对应缓存键失效。
- 部署监控：缓存命中率、回源延迟、淘汰次数。
验收标准：
- 失效后首次读取返回新数据（验证 TTL 和主动失效）。
- 并发回源时数据库连接数不超过阈值（如 100 QPS）。
- 缓存命中率在业务高峰期不低于 90%。
- 模拟雪崩场景（批量失效）下系统响应时间 ≤ 500ms。
架构决策要点：失效策略必须与业务隔离级别对齐——读多写少场景优先选 TTL + 预加载，写高频场景优先主动失效 + 异步一致。本章模型为后续所有失效策略（LRU、LFU、预失效、延迟失效等）提供通用数据流基础。