3. 缓存穿透、击穿、雪崩：问题定义、产生原因与经典解决方案

在分布式缓存系统中，缓存穿透、缓存击穿与缓存雪崩是三种最典型的高频故障模式。它们虽然都表现为“缓存失效导致后端压力骤增”，但问题发生的范围、触发条件与影响面截然不同。架构师必须能够从服务边界与数据流的角度精准区分这三种场景，并针对性地设计防御策略。

3.1 问题定义与核心差异

下表从故障范围、触发原因、影响对象三个维度对三种故障进行对比，帮助建立清晰的认知边界。

3.2 缓存穿透：问题定义与解决方案

3.2.1 产生原因

缓存穿透是指客户端请求的数据在缓存和数据库中都不存在。由于缓存中查不到该 Key，每次请求都会穿透到数据库层。攻击者常利用此漏洞，构造大量不存在的 Key 进行恶意请求，导致数据库连接耗尽。

3.2.2 经典解决方案

• 方案一：缓存空对象（Null Object）
  当数据库查询结果为空时，仍然将该 Key 写入缓存，但设置一个较短的过期时间（如 30~60 秒）。后续相同请求直接命中缓存空对象，避免穿透 DB。
• 方案二：布隆过滤器（Bloom Filter）
  在缓存层之前增加布隆过滤器，将所有可能存在的数据 Key 哈希到位数组中。请求到达时先通过布隆过滤器判断 Key 是否存在，若不存在则直接拒绝，避免无效查询进入缓存和 DB。
• 方案三：参数校验与限流
  在网关或服务入口层对请求参数进行合法性校验，过滤明显不合规的 Key（如 ID 为负数、超长字符串等），并配合接口限流降低恶意请求的冲击。

3.3 缓存击穿：问题定义与解决方案

3.3.1 产生原因

缓存击穿特指一个被高频访问的“热点 Key”在失效的瞬间，大量并发请求同时回源到数据库加载数据。由于并发量极高，数据库瞬间承受巨大压力，可能导致连接池耗尽或响应超时。

3.3.2 经典解决方案

• 方案一：互斥锁（Mutex Lock）
  当缓存失效时，只允许一个线程去数据库加载数据，其他线程等待。实现方式包括 Redis 的 SETNX 命令或分布式锁组件（如 Redisson）。
• 方案二：逻辑过期 + 异步刷新
  缓存数据不设置物理过期时间，而是在数据中嵌入一个逻辑过期字段。后台守护线程定期检查热点 Key 的逻辑过期时间，提前异步刷新缓存。请求线程永远不直接回源 DB。
• 方案三：热点 Key 永不过期
  对于极其重要的热点数据，直接设置为永不过期，通过后台定时任务或消息队列主动更新缓存内容。

3.4 缓存雪崩：问题定义与解决方案

3.4.1 产生原因

缓存雪崩有两种典型触发场景：场景A：大量缓存 Key 设置了相同的过期时间，在同一时刻集体失效，导致所有请求同时回源 DB；场景B：缓存节点（如 Redis 集群）发生宕机或网络分区，整个缓存层不可用，流量直接倾泻到数据库。

3.4.2 经典解决方案

• 方案一：过期时间随机化
  在设置缓存过期时间时，在基础过期时间上增加一个随机偏移量（如 ±10%~30%），避免大量 Key 同时过期。
• 方案二：缓存集群高可用
  部署 Redis 主从 + Sentinel 哨兵模式或 Redis Cluster 分片模式，实现自动故障转移。配合多级缓存（本地缓存 + 分布式缓存）进一步降低单点风险。
• 方案三：服务降级与熔断
  在数据库访问层配置限流和熔断组件（如 Hystrix、Sentinel）。当检测到 DB 负载超过阈值时，直接返回降级响应（如默认数据或错误提示），保护数据库不被击垮。
• 方案四：预热与双缓存
  在系统上线或大促前，提前将热点数据加载到缓存中。使用双缓存策略（主缓存 + 备用缓存），主缓存失效时读取备用缓存，避免直接回源。

3.5 三种故障的防御体系对比

下表从架构层面总结三种故障的防御策略选择，帮助架构师在系统设计阶段进行技术选型。

3.6 三种故障的请求流程对比

下面的 SVG 图从请求路径的角度，直观展示三种故障发生时流量如何绕过或冲击缓存层，以及对应的防御拦截点。

3.7 工程落地实践：代码示例

以下代码片段展示使用 Redis SETNX 实现缓存击穿互斥锁的核心逻辑，以及缓存空对象防御穿透的典型实现。

// 缓存击穿防御：互斥锁回源
public String getWithMutex(String key) {
    String value = redis.get(key);
    if (value != null) {
        return value;
    }
    // 尝试获取分布式锁
    String lockKey = "lock:" + key;
    boolean locked = redis.setnx(lockKey, "1", 30, TimeUnit.SECONDS);
    if (locked) {
        try {
            // 双重检查，防止等待期间其他线程已加载
            value = redis.get(key);
            if (value == null) {
                value = db.query(key);
                redis.set(key, value, 300, TimeUnit.SECONDS);
            }
            return value;
        } finally {
            redis.del(lockKey);
        }
    } else {
        // 未获取到锁，等待后重试
        Thread.sleep(50);
        return getWithMutex(key);
    }
}

// 缓存穿透防御：缓存空对象
public String getWithNullCache(String key) {
    String value = redis.get(key);
    if (value != null) {
        // 区分空对象标记
        if ("NULL_VALUE".equals(value)) {
            return null;
        }
        return value;
    }
    value = db.query(key);
    if (value == null) {
        // 缓存空对象，过期时间较短
        redis.set(key, "NULL_VALUE", 60, TimeUnit.SECONDS);
        return null;
    }
    redis.set(key, value, 300, TimeUnit.SECONDS);
    return value;
}

3.8 架构决策总结

在分布式系统架构中，缓存穿透、击穿与雪崩的防御不是孤立的技术点，而是需要贯穿在服务边界设计、缓存策略选型与高可用架构中的系统性工程。架构师应遵循以下原则：

• 分层防御： 在网关层、缓存层、数据库层分别部署不同的防御手段，形成纵深防护体系。
• 提前规划： 在系统设计阶段就识别出热点 Key 和可能的雪崩场景，而不是在故障发生后被动补救。
• 可观测性： 对缓存命中率、回源 QPS、锁等待时间等指标进行实时监控，及时发现异常模式。