1. 课程导论：为什么服务边界是缓存一致性的核心战场？
1.1 从单体到微服务：缓存一致性的挑战演变
在单体架构时代，缓存一致性是一个相对可控的问题。所有业务逻辑、数据访问和缓存操作都运行在同一个进程内，开发者可以通过本地锁、事务边界和强一致的数据库来保证缓存与数据源之间的同步。然而，当架构向微服务演进后，服务边界成为了缓存一致性的核心战场。
微服务架构将原本单一的应用拆分为多个独立部署、独立数据存储的服务。每个服务都有自己的缓存层，数据在多个服务之间通过远程调用（RPC/HTTP）进行流转。这种架构带来了以下根本性的挑战：
- 数据所有权分散：同一份业务数据可能被多个服务缓存，但只有一个服务拥有写入权限。
- 跨服务事务缺失：分布式环境下，无法使用本地数据库事务来协调缓存更新与数据更新。
- 网络延迟与不确定性：缓存失效通知、数据同步消息可能延迟、丢失或重复。
- 缓存粒度与边界错位：服务A缓存了用户信息，服务B也缓存了同一用户信息，但更新路径不同。
核心观点： 缓存一致性问题在单体架构中是“技术问题”，在微服务架构中则演变为“架构问题”。服务边界决定了数据流动的路径，也决定了缓存不一致的根源。
1.2 单体 vs 微服务：缓存一致性挑战对比
| 维度 | 单体架构 | 微服务架构 |
|---|---|---|
| 缓存位置 | 进程内缓存（本地堆/堆外） | 分布式缓存（Redis/Memcached）+ 本地缓存 |
| 数据一致性模型 | 强一致性（本地事务保证） | 最终一致性（异步消息/事件驱动） |
| 失效传播 | 方法调用直接失效 | 网络RPC/消息队列异步通知 |
| 并发控制 | 本地锁（synchronized/ReentrantLock） | 分布式锁（Redis Redlock/ZooKeeper） |
| 缓存穿透/击穿 | 单点限流+本地互斥 | 分布式限流+全局互斥+布隆过滤器 |
| 运维复杂度 | 低（单机部署） | 高（多集群、多区域、网络分区） |
1.3 服务边界带来的三大缓存一致性困境
- 困境一：写扩散与读扩散
- 服务A写入数据库后，需要通知所有可能缓存了该数据的服务B、C、D进行失效。
- 通知链路越长，不一致窗口越大。
- 困境二：缓存与数据库的双写冲突
- 先更新数据库还是先删除缓存？
- 在跨服务调用场景下，这个顺序问题会被放大：服务A更新DB成功，但通知服务B删除缓存失败，导致脏数据。
- 困境三：本地缓存与分布式缓存的层级不一致
- 服务实例的本地缓存（Caffeine/Guava）与全局Redis缓存之间存在时间差。
- 服务实例重启、扩缩容时，本地缓存自动失效，但全局缓存可能仍保留旧数据。
1.4 服务边界视角的缓存一致性架构图
下图展示了从单体到微服务演进过程中，缓存一致性问题的核心变化：
1.5 课程核心脉络
本课程将从服务边界的视角出发，系统性地解决缓存一致性问题。我们将按照以下路径展开：
- 第一部分：理论基础 — 缓存一致性模型、CAP理论在缓存场景的体现、服务边界对一致性的影响。
- 第二部分：模式与策略 — Cache-Aside、Read-Through/Write-Through、Write-Behind、双删策略、延迟双删、版本号方案。
- 第三部分：工程落地 — 分布式缓存选型（Redis Cluster/Twemproxy）、本地缓存与全局缓存协同、缓存失效通知的可靠投递。
- 第四部分：高级实战 — 多级缓存架构、缓存预热与防击穿、分布式锁在缓存更新中的应用、最终一致性补偿机制。
- 第五部分：运维与治理 — 缓存监控、一致性巡检、故障演练、容量规划。