防止redis缓存穿透的核心策略是避免大量请求直接访问数据库，主要通过以下四种方案实现：1. 缓存空对象，在数据库查询结果为空时缓存空值并设置较短过期时间，优点是实现简单但可能浪费存储资源；2. 使用布隆过滤器，预先加载所有可能存在的key以判断元素是否存在，优点是性能高但存在误判率且维护复杂；3. 采用互斥锁限制缓存未命中时仅一个线程查询数据库，优点是有效降低穿透风险但影响性能；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判断为存在。为了应对这种情况，可以采取以下措施：
- 设置合理的误判率： 在初始化布隆过滤器时，可以设置一个合理的误判率。误判率越低，需要的存储空间越大。
- 定期重建布隆过滤器： 定期从数据库中加载数据，重建布隆过滤器。这样可以避免布隆过滤器中的数据与数据库中的数据不一致。
- 监控布隆过滤器的效果： 监控布隆过滤器的命中率和误判率，如果发现误判率过高，可以调整布隆过滤器的参数或者重建布隆过滤器。
缓存穿透是一个需要重视的问题，需要根据具体的业务场景选择合适的防护方案。没有一种方案是万能的，需要综合考虑各种因素，才能有效地解决缓存穿透问题。
