1. 课程导论：缓存一致性问题在微服务架构中的重要性，服务边界划分对缓存一致性的影响
1.1 为什么缓存一致性是微服务架构的“阿喀琉斯之踵”
在单体架构向微服务架构演进的过程中，缓存从“性能加速器”变成了“数据一致性放大器”。单体应用内，缓存与数据库通常处于同一进程或同一事务边界内，一致性由本地锁和事务管理器保障。而在微服务架构中，每个服务拥有独立的数据库和缓存实例，服务间通过远程 API 或消息队列通信——缓存一致性问题从局部矛盾升级为全局系统性风险。
以下表格对比了单体架构与微服务架构下缓存一致性的核心差异：
| 对比维度 | 单体架构 | 微服务架构 |
|---|---|---|
| 缓存与数据库归属 | 同一进程/同一事务 | 每个服务独立拥有 |
| 一致性保障机制 | 本地锁 + 事务回滚 | 分布式事务 / 最终一致性 |
| 故障影响范围 | 单节点 | 跨服务级联 |
| 缓存失效延迟 | 毫秒级（本地内存） | 秒级甚至分钟级（网络+队列） |
| 排查复杂度 | 低（单进程日志） | 高（分布式链路追踪） |
关键认知： 微服务架构下，缓存一致性不再是“缓存与数据库”的二元关系，而是“服务A缓存 → 服务A数据库 → 服务B数据库 → 服务B缓存”的多跳传播链。任何一跳出现延迟或失败，都会导致用户读到过期数据。
1.2 服务边界划分：缓存一致性的“隐形设计决策”
服务边界的划分方式直接决定了缓存一致性的实现成本和故障模式。常见的边界划分策略有三种，每种对缓存一致性的影响截然不同：
- 按业务实体划分（如订单服务、用户服务）：数据自然解耦，但跨服务查询需要多次缓存穿透，一致性依赖最终同步。
- 按读写比例划分（如读服务、写服务）：写服务负责更新数据库并主动失效读服务的缓存，但网络分区时读服务可能长期持有脏数据。
- 按数据热度划分（如热数据服务、冷数据服务）：热数据服务使用本地缓存，冷数据服务直连数据库，边界模糊时容易产生双写冲突。
下面这张 SVG 图展示了不同服务边界划分下，缓存一致性故障的典型传播路径：
1.3 缓存一致性的三种典型故障模式
根据服务边界划分方式的不同，缓存一致性故障可归纳为以下三种典型模式：
| 故障模式 | 触发场景 | 典型表现 | 影响等级 |
|---|---|---|---|
| 脏读 | 服务A更新DB后未及时失效缓存A，后续请求读到旧数据 | 用户看到已取消的订单仍显示“待支付” | 严重 |
| 缓存穿透 | 服务B缓存未命中后查DB，但DB中数据已被服务A删除 | 大量请求直接打到DB，导致连接池耗尽 | 灾难 |
| 缓存雪崩 | 多个服务同时失效缓存，导致DB瞬间承受数倍流量 | 数据库CPU 100%，服务整体不可用 | 灾难 |
实战警示： 在服务边界划分不合理的场景下（例如将“订单状态”和“库存扣减”拆到两个服务但共用同一缓存键前缀），脏读和缓存穿透往往同时发生。排查时不要孤立看待单一故障，应从服务边界和数据流两个维度联合分析。
1.4 课程核心脉络：从故障定位到体系化防御
本课程将围绕以下主线展开，帮助学员建立从“故障发现”到“根因定位”再到“防御加固”的完整能力：
- 第1-3章：基础与原理 — 缓存一致性理论、PostgreSQL 与 Redis 的交互机制、服务边界划分的影响。
- 第4-10章：故障排查实战 — 通过 7 个真实案例，覆盖脏读、缓存穿透、缓存雪崩、双写冲突、消息延迟等场景。
- 第11-15章：监控与告警 — 基于 PostgreSQL 慢查询、WAL 日志、Redis 键空间通知的监控体系搭建。
- 第16-20章：防御与治理 — 缓存失效策略、分布式锁、CDC 同步、服务边界重构等治理方案。
- 第21-25章：SRE 运维与自动化 — 故障自愈、混沌工程、容量规划、缓存预热与降级。
- 第26-30章：架构演进与总结 — 从“缓存+数据库”到“事件驱动+CQRS”的架构演进路径。
学习建议： 如果你当前正面临缓存一致性问题，建议优先阅读第4-10章的故障案例，带着实际问题回到前3章夯实理论基础，效率更高。