Redis 缓存穿透与雪崩防御：布隆过滤器与过期随机化

在高并发系统中，Redis 作为缓存层极大地提升了系统性能，但同时也面临两大著名问题——缓存穿透与缓存雪崩。本教程将深入浅出地讲解这两种问题的本质，并提供经过生产验证的防御手段：布隆过滤器应对穿透，过期随机化缓解雪崩。

了解缓存穿透与缓存雪崩

在引入解决方案之前，我们必须清楚每个问题的发生场景和根因。

缓存穿透

缓存穿透是指查询一个根本不存在的数据。由于缓存中没有该数据，且数据库也没有，后续所有对该数据的查询都会绕过缓存直接压向数据库。当这类非法请求量巨大时，数据库可能因过载而崩溃。

典型场景

• 攻击者故意查询 id=-1 或业务上不可能存在的键。
• 自身业务逻辑缺陷，导致大量不存在的键被请求。

放大效应
因为缓存层不具备“放过不存在数据”的判断能力，每次请求都穿透到持久层，缓存形同虚设。

缓存雪崩

缓存雪崩是指大面积缓存在同一时刻失效，或Redis 集群整体宕机，致使海量请求瞬间涌入数据库，造成数据库压力陡增甚至宕机。

典型场景

• 批量加载缓存时设置了相同的过期时间，导致这些缓存在同一时间点集体失效。
• 缓存服务器重启或网络不可用，导致所有请求无法命中缓存。

后果
数据库压力指数级增长，极易引发连锁故障，最终导致整个服务不可用。

理解了问题，下面我们聚焦核心的防御方案。

防御缓存穿透：布隆过滤器

缓存穿透的核心难点在于：无法快速判断一个 key 是否“绝对不存在”。如果能在缓存层前面设置一道屏障，立即拦截对不存在 key 的查询，就能保护数据库。这道屏障通常借助**布隆过滤器（Bloom Filter）**实现。

布隆过滤器原理

布隆过滤器是一个概率型数据结构，由一个很长的二进制位数组和一系列哈希函数组成。它用于检测一个元素是否属于一个集合，但存在一定的误判率。

• 如果布隆过滤器说“不存在”，则元素一定不在集合中（100% 准确）。
• 如果布隆过滤器说“存在”，元素可能实际上不存在（存在一定的误判率）。

对于缓存穿透场景，我们只需要关心“绝对不存在”的判断，即当布隆过滤器返回“该 key 不存在”时，直接拒绝请求，不再查询缓存和数据库。少数误判（认为存在但实际不存在）的请求仍然会穿透，但概率可控，且可通过调节过滤器参数将误判率降至极低。

高效之处
布隆过滤器占用的内存极小，一个亿级数据量、1% 误判率的过滤器仅需约几十 MB 空间，完全可以全量存储在 Redis 或应用内存中。

集成 Redis 布隆过滤器

常用的方案有两种：使用 Redis 官方的 RedisBloom 模块，或使用 Redisson 客户端的内置布隆过滤器。

使用 Redisson 的布隆过滤器（Java 示例）

Redisson 以抽象封装的方式支持基于 Redis 的分布式布隆过滤器，无需额外安装模块。

初始化并构建过滤器

RBloomFilter<String> bloomFilter = redisson.getBloomFilter("productIdFilter");
// 初始化：预期插入元素数量 1000000，期望误判率 0.03
bloomFilter.tryInit(1000000L, 0.03);

在数据写入时添加元素

// 当数据库插入一条新数据时，同步将其 ID 加入布隆过滤器
bloomFilter.add("product_1001");

在查询时进行拦截

public Product getProduct(String productId) {
    // 1. 布隆过滤器判断是否存在
    if (!bloomFilter.contains(productId)) {
        // 直接返回不存在，不查询缓存和数据库
        return null; // 或抛出自定义异常
    }
    // 2. 查询缓存
    Product product = redisTemplate.opsForValue().get(productId);
    if (product != null) {
        return product;
    }
    // 3. 查询数据库
    product = database.findById(productId);
    if (product != null) {
        redisTemplate.opsForValue().set(productId, product, 1, TimeUnit.HOURS);
    } else {
        // 即使数据库中不存在，也要缓存空值（设置极短过期时间），防止接下来的相同请求再次穿透
        // 但布隆过滤器已经拦截了大部分这种情况
    }
    return product;
}

注意事项

• 布隆过滤器需要在数据写入时同步更新，否则新数据可能被误判为不存在。
• 布隆过滤器不支持删除操作（可使用计数布隆过滤器，但复杂度上升）。若数据删除频繁，可结合缓存空值等其他手段。
• 定期评估误判率和容量，避免因数据量增长导致误判率显著上升。

防御缓存雪崩：过期随机化

缓存雪崩多由于“同时过期”触发。要避免集体失效，核心思路是打散缓存的过期时间，不让它们在同一时刻集体过期。

过期时间随机化策略

在设置缓存有效期时，增加一个随机波动值，让每个 key 的 TTL 分布在不同的时间点。

基础公式

实际过期时间 = 基础过期时间 + random(0, 最大随机偏移)

代码示例（Spring Data Redis）

public void setCache(String key, Object value, long baseExpireSeconds, long maxRandomOffsetSeconds) {
    long randomOffset = ThreadLocalRandom.current().nextLong(maxRandomOffsetSeconds + 1);
    long expireSeconds = baseExpireSeconds + randomOffset;
    redisTemplate.opsForValue().set(key, value, expireSeconds, TimeUnit.SECONDS);
}

例如缓存商品详情，基础过期 30 分钟（1800秒），随机偏移设为 600 秒，则实际过期时间分布在 1800 ~ 2400 秒之间。这样即使大量商品同时被缓存，它们的过期点也会分散在 10 分钟的窗口内，极大缓解了数据库的瞬时压力。

对于热点数据的特殊处理

• 热点键本身就承载极高并发，即使过期时间错开，单键过期重新加载时仍可能对数据库造成压力。此时可结合**互斥锁（Mutex）**或“逻辑过期”方案，让只有一个线程去加载数据库，其他线程等待或返回旧值。

结合互斥锁与高可用

过期随机化解决了“同时过期”导致的雪崩，但若 Redis 本身宕机，同样会造成雪崩。因此需要从架构层面增强缓存层的可用性：

• Redis 哨兵（Sentinel）或集群（Cluster）：做主从自动切换和分片，避免单点故障。
• 多级缓存策略：本地缓存（如 Caffeine）作为一级缓存，Redis 作为二级缓存。即使 Redis 短暂不可用，本地缓存仍能抵挡部分请求。
• 限流与降级：当数据库压力过高时，启用限流策略，并对非核心服务进行服务降级，甚至直接返回提示信息或兜底数据。

互斥锁示例（防止单键过期后大量线程同时查库）

public Product getProductWithLock(String productId) {
    String cacheKey = "product:" + productId;
    Product product = redisTemplate.opsForValue().get(cacheKey);
    if (product != null) return product;

    String lockKey = "lock:product:" + productId;
    try {
        // 尝试获取分布式锁，设置合理超时防止死锁
        boolean locked = redisTemplate.opsForValue().setIfAbsent(lockKey, "1", 10, TimeUnit.SECONDS);
        if (locked) {
            product = database.findById(productId);
            // 计算带随机的过期时间
            long expire = 1800 + ThreadLocalRandom.current().nextLong(600);
            redisTemplate.opsForValue().set(cacheKey, product, expire, TimeUnit.SECONDS);
        } else {
            // 未拿到锁，短暂等待后重试
            Thread.sleep(50);
            return getProductWithLock(productId); // 递归重试，实际应限制次数
        }
    } finally {
        // 释放锁（需确保原子性，实际应使用 Lua 脚本）
        redisTemplate.delete(lockKey);
    }
    return product;
}

注意：上述锁实现仅为示意，生产环境建议使用 Redisson 的分布式锁以保证原子性和健壮性。

总结与最佳实践

最佳实践清单

1. 所有缓存业务都应采用过期随机化，哪怕缓存数量不大，也是低成本的风险规避。
2. 布隆过滤器维护需要与写入流程无缝衔接，并在业务增长时动态调整容量（可重建过滤器）。
3. 监控布隆过滤器误判率与内存占用，当实际误判超过设定值时，及时扩容或更换哈希策略。
4. 永远不要只依赖单一防护手段：例如布隆过滤器拦截穿透，同时配合空值缓存；雪崩防护除了随机过期，还应做好熔断、限流和缓存预热。
5. 预设极端场景下的兜底方案：如 Redis 完全不可用时，系统能够平滑降级，保证核心功能可用。

通过理解缓存穿透与雪崩的系统性风险，并合理运用布隆过滤器和过期随机化，你可以为后端服务构建一道坚固的缓存防线。动手在项目里实践这些模式吧——一旦通过压测和实战检验，你会发现系统的稳定性有质的飞跃。