3. 缓存失效模式：TTL过期、主动失效、被动失效、写穿透、写回等常见失效策略的原理与对比
在分布式缓存系统中，失效策略决定了缓存数据何时被移除或更新，是保障缓存一致性的核心机制。不同的失效模式在一致性、性能、复杂度上各有取舍。本节将系统梳理五种主流失效策略的原理，并通过对比表格和架构图帮助理解其适用场景。
3.1 TTL过期（Time-To-Live Expiration）
TTL过期是最基础的被动失效策略。缓存数据在写入时被赋予一个生存时间（如 300 秒），当计时器归零后，缓存条目自动失效，后续读取将触发回源加载。
- 原理：缓存客户端或中间件为每个 key 记录写入时间戳 + TTL 值，通过惰性删除或定时扫描清理过期条目。
- 优点：实现简单，无需外部协调；适合对一致性要求不高的场景（如用户会话、静态资源配置）。
- 缺点：在 TTL 窗口内数据可能已过时；大量 key 同时过期可能导致缓存雪崩。
实践建议：为 TTL 添加随机偏移量（如基础 TTL ± 10%），避免大量 key 在同一秒集中失效。
3.2 主动失效（Active Invalidation）
当后端数据库发生写操作时，应用层或中间件主动向缓存发送删除或更新指令，强制移除或刷新对应 key。这是实现强一致性的常用手段。
- 原理：写请求先更新数据库，然后通过消息队列、事件总线或直接 RPC 通知缓存节点执行失效操作。
- 优点：数据变更后能快速反映到缓存，一致性窗口极小。
- 缺点：引入额外的网络开销和复杂度；若失效消息丢失，缓存将永久存留脏数据。
关键风险：主动失效依赖消息可靠性。建议结合“失效确认 + 重试机制”或“TTL 兜底”来防止消息丢失导致的永久不一致。
3.3 被动失效（Passive Invalidation / Lazy Loading）
被动失效不主动清理缓存，而是让缓存条目自然存在，直到被读取时校验其有效性。常见实现包括“缓存旁路（Cache-Aside）”模式中的过期校验。
- 原理：读取缓存时，检查数据版本号或时间戳是否与源端一致；若不一致则回源加载并更新缓存。
- 优点：读多写少场景下减少无效的缓存清理操作；实现相对简单。
- 缺点：每次读取都需额外校验，增加读延迟；在写频繁场景下缓存命中率可能下降。
3.4 写穿透（Write-Through）
写穿透是一种同步写入策略：应用将数据同时写入缓存和数据库，且以缓存为写入入口。缓存层负责将数据同步到持久化存储。
- 原理：应用只与缓存交互，缓存内部实现双写逻辑。写入成功后才返回客户端。
- 优点：缓存与数据库始终一致（无脏数据窗口）；读性能高，因为缓存始终是最新数据。
- 缺点：写延迟增加（需等待两次写入完成）；缓存故障会影响写入可用性。
3.5 写回（Write-Back / Write-Behind）
写回策略允许应用先将数据写入缓存，立即返回成功，然后由缓存异步地将数据批量或延迟写入数据库。
- 原理：缓存作为写缓冲区，积累一定量或间隔时间后，后台线程将脏数据刷入数据库。
- 优点：写吞吐量极高（异步批量合并）；适合日志、计数、IoT 传感器数据等写密集型场景。
- 缺点：缓存崩溃可能导致数据丢失；缓存与数据库之间存在短暂不一致窗口。
3.6 五种失效策略综合对比
| 策略 | 一致性等级 | 写延迟 | 读延迟 | 实现复杂度 | 典型场景 |
|---|---|---|---|---|---|
| TTL 过期 | 弱（窗口期长） | 低 | 低（命中时） | 低 | 会话、静态配置、非关键数据 |
| 主动失效 | 强（接近实时） | 中（+通知开销） | 低 | 中高 | 订单状态、库存、账户余额 |
| 被动失效 | 最终一致 | 低 | 中（+校验开销） | 中 | 内容管理系统、用户资料 |
| 写穿透 | 强（同步双写） | 高（双写等待） | 低 | 中 | 金融交易、配置中心 |
| 写回 | 最终一致（有窗口） | 极低（异步） | 低 | 高 | 日志聚合、点击流、监控指标 |
3.7 失效策略选择决策流程
下图展示了在 OpenAPI 契约落地过程中，根据业务一致性要求和性能目标选择失效策略的决策路径。
3.8 组合策略与 OpenAPI 契约落地
在实际的微服务架构中，单一失效策略往往无法满足所有场景。推荐采用分层组合方式：
- 核心数据（如订单状态）：使用主动失效 + 写穿透，在 OpenAPI 契约中显式声明
x-cache-invalidation: active和x-cache-write-mode: write-through。 - 非核心数据（如商品详情）：使用TTL + 被动失效，契约中标注
x-cache-ttl: 300和x-cache-stale-while-revalidate: 60。 - 写密集型数据（如操作日志）：使用写回，契约中声明
x-cache-write-mode: write-behind和x-cache-flush-interval: 5s。
OpenAPI 扩展示例：通过自定义
x-cache-policy 字段，将失效策略显式化到接口契约中，使客户端和网关能够自动适配缓存行为。
paths:
/api/orders/{id}:
get:
x-cache-policy:
ttl: 120
stale-while-revalidate: 30
invalidation: passive
put:
x-cache-policy:
invalidation: active
write-mode: write-through