📚 课程目录第4章缓存一致性理论

4. 缓存一致性理论：缓存穿透、缓存击穿、缓存雪崩、数据一致性的CAP理论在缓存中的体现

在构建基于Docker的缓存一致性测试环境之前，必须深入理解缓存系统中常见的三大故障场景以及分布式系统核心的CAP理论在缓存中的具体映射。这些理论是后续设计测试用例、配置缓存策略和诊断问题的基石。

定义：查询一个根本不存在的数据。由于缓存中不命中，请求直接穿透到后端数据库，导致数据库压力骤增。恶意攻击者常利用此漏洞扫描不存在的ID。

  核心特征：缓存和数据库中均无该数据，每次请求都直达数据库。

方案	原理	优点	缺点
缓存空对象	将查询结果为null的key也缓存起来，设置较短的过期时间（如60秒）。	实现简单，能有效拦截大量穿透请求。	会占用额外内存；可能导致短期数据不一致（空对象过期前，真实数据写入后无法立即查询）。
布隆过滤器 (Bloom Filter)	将所有可能存在的数据哈希到一个足够大的bitmap中。请求到达时先通过布隆过滤器判断key是否存在。	内存占用极低，不存在空对象的内存浪费问题。	存在一定的误判率（可能将不存在的数据判为存在）；无法删除元素，更新复杂。

定义：一个热点key在缓存过期的瞬间，大量并发请求同时涌入，全部穿透到数据库，导致数据库瞬间负载过高甚至宕机。

注意区分：击穿针对的是单个热点key的过期瞬间，而穿透针对的是不存在的key。

定义：在某一时刻，大量缓存key同时失效，或者缓存节点宕机，导致所有请求全部落到数据库上，引发连锁反应。

  典型场景：所有缓存key的过期时间都设置为同一时刻（如午夜0点），或者Redis集群主节点全部宕机。

策略	说明
过期时间打散	在基础过期时间上增加一个随机值（如1-5分钟），避免集体失效。
多级缓存	本地缓存（如Caffeine）+ 分布式缓存（如Redis），本地缓存作为第一道屏障。
缓存高可用	使用Redis Sentinel或Redis Cluster，避免单点故障。
限流降级	对数据库访问进行限流，超出阈值的请求直接返回默认值或错误提示。

CAP理论指出，分布式系统无法同时满足一致性 (Consistency)、可用性 (Availability)和分区容错性 (Partition Tolerance)，最多只能同时满足其中两项。在缓存系统中，这一理论直接决定了缓存与数据库之间的数据同步策略。

缓存中的CAP权衡：大多数缓存系统（如Redis）在发生网络分区时，优先保证可用性 (AP)，牺牲强一致性，最终通过补偿机制达到最终一致性。

模型	CAP倾向	典型实现	适用场景
强一致性	CP	分布式锁 + 同步写数据库和缓存	金融交易、库存扣减
最终一致性	AP	异步消息队列 + 缓存失效/更新	用户信息、商品详情
弱一致性	AP	缓存过期后重新加载	非关键统计数据、排行榜

在实际的缓存一致性测试中，最核心的挑战是缓存与数据库之间的数据同步。以下是四种主流策略及其在CAP理论下的定位：

先更新数据库，再删除缓存 (Cache-Aside Pattern)：最常用策略。更新数据库后，直接删除缓存，下次读取时重新加载。存在短暂不一致窗口（数据库已更新，缓存尚未删除）。
先更新数据库，再更新缓存：并发写操作可能导致脏数据（后写的数据库被先写的缓存覆盖）。
先删除缓存，再更新数据库：高并发下，删除缓存后，另一个线程可能读取旧数据并写入缓存，导致数据不一致。
延迟双删：先删除缓存，再更新数据库，休眠一小段时间（如500ms），再次删除缓存。牺牲性能换取更高的一致性保障。

测试环境搭建提示：在后续的Docker Compose环境中，我们将通过模拟网络延迟、节点宕机、并发写入等场景，实际验证上述策略在CAP理论下的表现。请重点关注“先更新数据库，再删除缓存”策略在Redis主从复制延迟下的数据不一致窗口。