4. 缓存一致性问题全景：读写不一致、最终一致性延迟、缓存雪崩、穿透、击穿的根源分析

在分布式系统中，缓存是提升性能的核心手段，但引入缓存的同时也带来了数据一致性的挑战。本章从领域驱动设计的视角出发，系统梳理缓存一致性的五大经典问题：读写不一致、最终一致性延迟、缓存雪崩、缓存穿透和缓存击穿。我们将深入分析每个问题的根源，并探讨其在服务边界划分下的影响。

4.1 缓存一致性问题全景图

下图展示了缓存一致性问题的整体分类及其相互关系。理解这些问题的根源，是设计可靠缓存策略的前提。

4.2 读写不一致：根源与影响

读写不一致是最常见的缓存问题，指在写操作完成后，读操作仍然返回旧数据。其根源在于缓存与数据库的更新时序无法保证原子性。

4.2.1 典型场景

• 先更新数据库，再删除缓存：删除缓存失败时，后续读请求命中旧缓存。
• 先删除缓存，再更新数据库：在删除缓存后、更新数据库前，并发读请求将旧数据写入缓存。
• 双写并发：两个写线程同时操作，导致缓存与数据库数据不一致。

4.2.2 根源分析

4.3 最终一致性延迟：时间窗口的挑战

最终一致性延迟是指在异步同步模式下，从数据更新到缓存生效之间存在一个时间窗口，在此期间读请求可能获取到过期数据。

4.3.1 延迟来源

1. 异步消息队列延迟：消息积压、消费失败导致同步滞后。
2. 批量同步周期：定时任务刷新缓存，存在固定时间窗口。
3. 网络分区：节点间通信延迟或中断，导致数据同步失败。

4.3.2 延迟量化

4.4 缓存雪崩：大规模失效的连锁反应

缓存雪崩指大量缓存数据在同一时间过期，导致所有请求直接打到数据库，造成数据库压力骤增甚至宕机。

4.4.1 雪崩的典型成因

• 统一过期时间：所有缓存 key 设置了相同的 TTL。
• 缓存服务宕机：Redis 集群故障，所有缓存失效。
• 热点数据集中：多个业务共享同一缓存实例，故障影响面大。

4.4.2 雪崩的破坏路径

4.4.3 预防策略

4.5 缓存穿透：查询不存在的数据

缓存穿透指查询一个数据库中不存在的数据，由于缓存中没有该数据，每次请求都直接打到数据库。恶意攻击或系统缺陷可能放大此问题。

4.5.1 穿透的根源

• 业务逻辑缺陷：查询条件不合法，但未做校验。
• 恶意攻击：构造大量不存在的 key 进行请求。
• 数据删除：数据库数据被删除，但缓存未同步清理。

4.5.2 解决方案对比

4.6 缓存击穿：热点 key 的致命一击

缓存击穿指一个热点 key 在过期瞬间，大量并发请求同时访问该 key，导致所有请求都穿透到数据库。与雪崩不同，击穿针对的是单个热点 key。

4.6.1 击穿的发生条件

1. 存在一个高并发访问的热点 key。
2. 该 key 的缓存恰好过期。
3. 大量请求在过期瞬间同时到达。

4.6.2 防护机制

4.6.3 互斥锁实现示例

// 伪代码：互斥锁防止缓存击穿
public Object getData(String key) {
    Object data = cache.get(key);
    if (data != null) {
        return data;
    }
    
    // 尝试获取分布式锁
    if (lock.tryLock(key)) {
        try {
            // 双重检查，防止其他线程已加载
            data = cache.get(key);
            if (data != null) {
                return data;
            }
            // 从数据库加载
            data = db.query(key);
            cache.set(key, data, TTL);
            return data;
        } finally {
            lock.unlock(key);
        }
    } else {
        // 等待其他线程加载完成
        Thread.sleep(50);
        return getData(key); // 递归重试
    }
}

4.7 问题根源总结与 DDD 映射