1. 课程导论：缓存一致性问题全景图与失效策略的核心价值

1.1 缓存一致性：分布式系统的“阿喀琉斯之踵”

在微服务与高并发架构中，缓存是提升性能的首选武器。然而，缓存与数据库之间的数据不一致问题，是导致线上故障、数据错乱、资损事故的头号技术债。缓存一致性并非单一技术问题，而是一组由更新时序、并发冲突、网络分区、中间件特性交织而成的复杂治理难题。

下图展示了缓存一致性问题的核心矛盾：当业务数据发生变更时，缓存中的旧数据与数据库中的新数据之间出现时间窗口，不同客户端可能读到不同版本的数据。

1.2 六大典型不一致场景

根据生产环境故障复盘，缓存不一致问题可归纳为以下六类高频场景。理解这些场景是设计失效策略的前提。

场景编号	场景名称	触发条件	典型后果
S1	先删缓存，后写数据库	并发读请求在缓存删除后、数据库写入前填充缓存	缓存中为旧数据，数据库为新数据
S2	先写数据库，后删缓存失败	数据库写入成功，缓存删除操作因网络/超时未执行	缓存永久保留旧数据
S3	双写并发时序错乱	两个线程同时写数据库和缓存，后写缓存的线程覆盖了先写但更新的数据	缓存与数据库最终状态不一致
S4	主从延迟 + 缓存未失效	写入主库后立即读从库，从库尚未同步，缓存也未失效	读到旧数据（从库 + 缓存双重旧）
S5	批量操作部分失败	批量更新中部分 key 缓存删除失败，部分成功	缓存数据局部不一致，排查困难
S6	缓存穿透 + 并发回源	缓存失效瞬间大量请求同时回源查询数据库	数据库压力激增，回源数据可能不一致

1.3 失效策略：从“被动淘汰”到“主动治理”

传统缓存失效策略（如 TTL 过期、LRU 淘汰）属于被动失效——缓存系统在内存不足或时间到期时自动删除数据。这种策略无法应对业务数据主动变更的场景。现代架构需要主动失效策略：当数据库发生写操作时，通过明确的契约和机制，主动通知缓存系统删除或更新对应数据。

失效策略的核心价值体现在三个维度：

1. 一致性保障：通过“先写库、后删缓存”或“延迟双删”等模式，将不一致窗口从秒级压缩到毫秒级。
2. 治理标准化：将失效行为从“代码隐性逻辑”提升为“OpenAPI 显式契约”，让上下游系统可观测、可测试、可审计。
3. 故障自愈：结合重试、补偿、监控机制，在缓存删除失败时自动修复，避免数据永久不一致。

1.4 本课程的技术栈与治理框架

本课程围绕 Redis + MySQL + Spring Boot 技术栈，以 OpenAPI 3.0 规范为契约载体，构建一套可落地的缓存一致性治理体系。整体框架分为四层：

层级	核心组件	职责
契约层	OpenAPI 规范 + 失效策略扩展字段	定义缓存失效的触发条件、目标 key、重试策略、补偿方式
执行层	失效策略引擎（延迟双删、异步删除、binlog 监听）	根据契约执行缓存失效操作，处理失败重试
观测层	失效事件日志 + 一致性指标 + 告警	记录每次失效操作的执行结果，监控不一致率
治理层	一致性巡检 + 补偿任务 + 人工介入 API	定期扫描不一致数据，触发自动或手动修复

1.5 本章小结

• 缓存一致性问题的本质是数据库写入与缓存更新之间的时序冲突，在高并发场景下被放大。
• 六大典型场景中，先删缓存后写库和写库后删缓存失败是最常见的故障根源。
• 失效策略从被动淘汰演进为主动治理，核心价值在于将不一致窗口从秒级压缩到毫秒级，并通过契约实现标准化。
• 本课程以 OpenAPI 契约 + 失效策略引擎 为核心，构建四层治理框架，覆盖定义、执行、观测、治理全链路。