首页 > 数据库 > Redis

Redis缓存穿透不用怕！这四种解决方案超实用

时间：2025-06-08 13:32:54 131浏览收藏

面对Redis缓存穿透，如何保障数据库安全？本文深入探讨了缓存穿透的识别方法，包括监控Key访问模式、数据库压力和日志分析等，并详细介绍了四种有效的防护方案：缓存空对象、布隆过滤器、互斥锁以及接口层校验。针对每种方案，文章剖析了其优缺点和适用场景，并给出了具体的代码示例。同时，还提供了应对布隆过滤器误判的策略，如设置合理误判率、定期重建和监控效果。通过综合运用这些方法，能有效避免大量请求直接冲击数据库，显著提升系统的稳定性和性能。选择合适的防护方案，并结合实际业务场景进行优化，是解决Redis缓存穿透问题的关键。

防止Redis缓存穿透的核心策略是避免大量请求直接访问数据库，主要通过以下四种方案实现：1. 缓存空对象，在数据库查询结果为空时缓存空值并设置较短过期时间，优点是实现简单但可能浪费存储资源；2. 使用布隆过滤器，预先加载所有可能存在的key以判断元素是否存在，优点是性能高但存在误判率且维护复杂；3. 采用互斥锁限制缓存未命中时仅一个线程查询数据库，优点是有效降低穿透风险但影响性能；4. 在接口层校验请求参数合法性，优点是减轻缓存与数据库压力但增加代码复杂度。选择防护方案需结合业务场景，同时建议在接口层进行参数校验，并对布隆过滤器的误判采取应对措施，如设置合理误判率、定期重建和监控效果，最终综合多种方法以高效解决缓存穿透问题。

redis如何防止穿透 redis缓存穿透的4种防护方案

防止Redis缓存穿透，核心在于避免大量请求直接打到数据库上。简单来说，就是当请求一个不存在的key时，不要让所有请求都去查数据库，而是要有应对策略。

解决Redis缓存穿透，可以从以下几个方面入手。

如何识别Redis缓存穿透？

识别缓存穿透，关键在于区分正常缓存未命中和恶意攻击。正常情况下，缓存未命中是零星的，而缓存穿透通常表现为：

特定key的请求量异常增高： 监控Redis的key访问模式，如果发现某个原本不热门的key突然被大量访问，且缓存未命中率很高，很可能存在穿透。
数据库压力异常增高： 即使Redis存在，数据库的读压力也应该相对稳定。如果数据库突然出现大量针对不存在数据的查询，也可能是缓存穿透的迹象。
日志分析： 分析应用服务器的日志，查找针对不存在key的查询请求。

更进一步，可以使用一些监控工具来辅助识别。例如，可以利用Prometheus和Grafana搭建监控系统，监控Redis的命中率、未命中率，以及数据库的查询量等指标。

缓存穿透的四种防护方案详解

缓存空对象：

这是最简单直接的方法。当数据库查询结果为空时，仍然将这个空结果缓存起来，但设置一个较短的过期时间。例如，可以设置为30秒或1分钟。

String key = "user:" + userId;
String userJson = redisTemplate.opsForValue().get(key);

if (StringUtils.isEmpty(userJson)) {
    User user = userService.getUserById(userId);
    if (user == null) {
        // 缓存空对象，过期时间设置为1分钟
        redisTemplate.opsForValue().set(key, "", 60, TimeUnit.SECONDS);
        return null; // 或者返回一个特定的空对象
    } else {
        userJson = JSON.toJSONString(user);
        redisTemplate.opsForValue().set(key, userJson, 1, TimeUnit.HOURS);
    }
}
return JSON.parseObject(userJson, User.class);

优点： 实现简单，对现有代码改动较小。

缺点： 缓存空对象仍然会占用Redis的存储空间，如果大量的key都不存在，会浪费一定的资源。另外，如果数据库后续插入了这条数据，缓存可能无法及时更新。

布隆过滤器：
布隆过滤器是一种概率型数据结构，用于判断一个元素是否存在于集合中。它可以告诉你某个元素“可能存在”或者“一定不存在”。
在缓存之前，将所有可能存在的key预先加载到布隆过滤器中。当请求到来时，先判断key是否存在于布隆过滤器中，如果不存在，则直接返回，避免查询Redis和数据库。
```
// 假设已经初始化了布隆过滤器 bloomFilter
String key = "user:" + userId;

if (!bloomFilter.mightContain(key)) {
    return null; // 直接返回，避免查询Redis和数据库
}

String userJson = redisTemplate.opsForValue().get(key);

// ... 后续逻辑
```
优点： 性能很高，可以有效过滤掉不存在的key，降低数据库压力。
缺点： 实现相对复杂，需要维护布隆过滤器的数据，并且存在一定的误判率（即可能将存在的key判断为不存在）。另外，如果数据库的数据发生变化，需要及时更新布隆过滤器。

互斥锁：

当缓存未命中时，使用互斥锁来限制只有一个线程去查询数据库，其他线程等待。这样可以避免大量请求同时穿透到数据库。

String key = "user:" + userId;
String userJson = redisTemplate.opsForValue().get(key);

if (StringUtils.isEmpty(userJson)) {
    // 使用分布式锁，例如Redisson
    RLock lock = redissonClient.getLock("lock:" + key);
    try {
        if (lock.tryLock(10, TimeUnit.SECONDS)) { // 尝试加锁，最多等待10秒
            try {
                User user = userService.getUserById(userId);
                if (user == null) {
                    redisTemplate.opsForValue().set(key, "", 60, TimeUnit.SECONDS);
                    return null;
                } else {
                    userJson = JSON.toJSONString(user);
                    redisTemplate.opsForValue().set(key, userJson, 1, TimeUnit.HOURS);
                }
            } finally {
                lock.unlock(); // 释放锁
            }
        } else {
            // 获取锁失败，可以稍后重试，或者返回一个默认值
            Thread.sleep(100); // 稍后重试
            return getUser(userId); // 递归调用
        }
    } catch (InterruptedException e) {
        Thread.currentThread().interrupt();
        return null;
    }
}
return JSON.parseObject(userJson, User.class);

优点： 可以有效避免大量请求同时穿透到数据库。

缺点： 性能相对较低，因为需要加锁和释放锁，会增加请求的响应时间。另外，如果锁的过期时间设置不合理，可能会导致死锁。

接口层校验：
在接口层对请求参数进行校验，例如，检查用户ID是否符合规范，是否在合理的范围内。如果参数不合法，则直接拒绝请求，避免无效请求穿透到缓存和数据库。
```
@GetMapping("/user/{userId}")
public User getUser(@PathVariable Long userId) {
    if (userId == null || userId <= 0 || userId > MAX_USER_ID) {
        return null; // 或者返回一个错误码
    }

    // ... 后续的缓存和数据库查询逻辑
}
```
优点： 可以有效过滤掉无效请求，减轻缓存和数据库的压力。
缺点： 需要在接口层增加额外的校验逻辑，可能会增加代码的复杂度。

如何选择合适的防护方案？

选择哪种防护方案，需要根据具体的业务场景和需求来决定。

如果缓存的数据量不大，且空结果不频繁， 可以选择缓存空对象。
如果需要处理大量的无效请求，且可以容忍一定的误判率， 可以选择布隆过滤器。
如果对性能要求较高，且需要保证数据的一致性， 可以选择互斥锁。
无论选择哪种方案，都应该在接口层进行参数校验， 过滤掉无效请求。

如何应对布隆过滤器的误判？

即使使用了布隆过滤器，仍然存在一定的误判率。也就是说，布隆过滤器可能会将一个不存在的key判断为存在。为了应对这种情况，可以采取以下措施：

设置合理的误判率： 在初始化布隆过滤器时，可以设置一个合理的误判率。误判率越低，需要的存储空间越大。
定期重建布隆过滤器： 定期从数据库中加载数据，重建布隆过滤器。这样可以避免布隆过滤器中的数据与数据库中的数据不一致。
监控布隆过滤器的效果： 监控布隆过滤器的命中率和误判率，如果发现误判率过高，可以调整布隆过滤器的参数或者重建布隆过滤器。

缓存穿透是一个需要重视的问题，需要根据具体的业务场景选择合适的防护方案。没有一种方案是万能的，需要综合考虑各种因素，才能有效地解决缓存穿透问题。

到这里，我们也就讲完了《Redis缓存穿透不用怕！这四种解决方案超实用》的内容了。个人认为，基础知识的学习和巩固，是为了更好的将其运用到项目中，欢迎关注golang学习网公众号，带你了解更多关于redis,互斥锁,缓存穿透,布隆过滤器,接口层校验的知识点！

redis 互斥锁缓存穿透布隆过滤器接口层校验