redis如何防止穿透 redis缓存穿透的4种防护方案-小浪学习网

防止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; // 或者返回一个错误码     }      // ... 后续的缓存和数据库查询逻辑 }
```
优点： 可以有效过滤掉无效请求，减轻缓存和数据库的压力。

缺点： 需要在接口层增加额外的校验逻辑，可能会增加代码的复杂度。