Redis 缓存失效三大经典场景

Corey2026/7/9大约 7 分钟面试题面试题

来源：Redis 缓存失效三大经典场景

在分布式高并发系统的设计中，Redis 无疑是提升性能的银弹。它通过内存的高速读写，为脆弱的数据库挡下了成千上万的 QPS。然而，引入缓存层也引入了新的复杂性。当缓存因为某些原因“失效”或“被绕过”时，流量会瞬间像洪水一样冲击数据库，导致系统雪崩。

本文将结合可视化架构图，深入剖析 Redis 缓存最经典的三大失效场景——穿透、击穿、雪崩，并提供生产级的防御策略。

一、缓存穿透 (Cache Penetration)

1. 场景复现：流量的“隐形杀手”

技术剖析： 缓存穿透是指查询一个根本不存在的数据。在正常的缓存策略中（Cache Aside Pattern），我们通常遵循“先查缓存，没有则查库，查到后回写缓存”的逻辑。但如果查询的 Key 在数据库中也不存在，那么这个 Key 永远不会被写入缓存。

这就导致了一个致命漏洞：如果恶意用户（或爬虫）构造海量不存在的 ID（如 id=-1 或随机 UUID）发起请求，这些请求将全部绕过 Redis，直接打在数据库上。此时，Redis 失去了防御作用，数据库连接池会瞬间被占满，导致正常的业务请求无法处理。

2. 硬核防御：布隆过滤器 (Bloom Filter)

原理深度： 为了解决穿透问题，我们需要在请求到达后端存储之前，就快速判断“这个 Key 是否可能存在”。布隆过滤器（Bloom Filter）是解决此类问题的最佳数据结构。

核心机制：它由一个很长的二进制向量（Bit Array）和一系列随机映射函数（Hash Functions）组成。当一个元素被加入集合时，通过 K 个 Hash 函数将这个元素映射成位数组中的 K 个点，并将它们置为 1。
空间效率：它极度节省空间。相比于 HashMap 存储完整的 Key，布隆过滤器仅需存储几个 Bit。如架构图所示，仅需 1.2MB 的内存即可映射 100 万条数据。
概率权衡：
如果布隆过滤器说不存在，则一定不存在（100% 拦截）。
如果布隆过滤器说存在，则可能存在（存在极低的误判率）。

架构落地： 在生产环境中，我们通常在 Redis 前置一层布隆过滤器。

请求进来，先问布隆过滤器：Key 存在吗？
若不存在，直接返回空，完全不访问 Redis 和 DB。
若存在（可能误判），再走正常的“查缓存 -> 查库”流程。

public Object getData(String key) {
    // 1. 查询缓存
    Object value = redis.get(key);
    if (value != null) return value;
    
    // 2. 缓存未命中，尝试获取互斥锁
    // SETNX key "1" EX 10 (设置过期时间防止死锁)
    if (redis.tryLock(lockKey)) {
        try {
            // Double Check: 再次查询缓存，防止重复查库
            value = redis.get(key);
            if (value != null) return value;
    
            // 3. 查询数据库
            value = db.query(key);
            // 4. 回写缓存
            redis.set(key, value);
        } finally {
            // 5. 释放锁
            redis.unlock(lockKey);
        }
    } else {
        // 6. 获取锁失败，休眠后重试
        Thread.sleep(50);
        return getData(key);
    }
    return value;
}

方案权衡：

CP 模型（强一致性）：互斥锁保证了只有一个线程去查库，避免了数据库压力，且保证了数据的一致性。
性能损耗：如架构图所示，Thread B 和 Thread C 需要等待，这会降低系统的吞吐量。如果业务追求极致的高可用（AP），可以考虑“逻辑过期”方案（即 Key 永不过期，但在 Value 中包含过期时间戳，由后台线程异步重建）。