最近在 Code Review 时看到一句话“用缓存空值解决缓存穿透的都是初学者。” 这句话虽然有点绝对但背后确实点出了一个很常见的问题很多团队一遇到缓存穿透第一反应就是“把空值也缓存起来”却很少去思考这个方案在高并发、大数据量场景下的副作用。缓存空值并不是不能用而是要搞清楚它适合什么场景以及它和布隆过滤器、互斥锁、参数校验这些手段之间的边界在哪里。这篇文章会从缓存穿透的本质讲起分析缓存空值方案的原理和隐患再给出布隆过滤器、互斥锁、请求校验等多种方案的对比最后用一个完整的 Java 示例把几种手段组合起来做成一个相对健壮的缓存穿透防护方案。无论你是刚接触 Redis 的初学者还是已经在生产环境维护缓存服务的开发者都能从中找到可以参考的落地思路。1. 缓存穿透到底是怎么发生的1.1 先从一条正常的缓存链路说起在讲缓存穿透之前先回顾一下大多数业务系统里的缓存访问流程。假设我们有一个商品详情接口用户通过商品 ID 查询商品信息。在没有缓存的情况下每次请求都会直接查询数据库数据库压力会随着请求量线性增长。引入 Redis 之后流程变成了这样请求到达服务端先查 Redis。Redis 中命中了数据直接返回。Redis 中没有命中查询数据库。数据库中存在数据把数据写回 Redis设置过期时间。返回数据给调用方。这个流程本身没有问题它能挡住大多数重复查询。但有一个特殊情况如果某个商品 ID 在数据库中根本不存在那么 Redis 中永远不会有它的缓存于是每次请求这个不存在的 ID 时都会穿透 Redis直接打到数据库上。1.2 缓存穿透的定义缓存穿透指的就是查询一个数据库中不存在的数据因为缓存中也没有所以每次请求都会绕过缓存直接访问数据库。当这种请求量很大时数据库会被大量无效查询拖垮。这里要注意区分穿透、击穿和雪崩很多文章会把这三个概念混在一起缓存穿透查询一个不存在的数据缓存和数据库都没有。绕过缓存打到数据库。缓存击穿某个热点 key 在缓存过期的瞬间大量请求同时访问数据库。缓存里有数据但刚好过期了。缓存雪崩大量 key 在同一时间段内集中过期导致大量请求同时访问数据库。三者的共同点是“大量请求打到数据库”但原因完全不同。缓存穿透是数据本身不存在击穿是热点 key 过期雪崩是大面积 key 过期。搞清楚这个区别才能对症下药。1.3 哪些场景容易引发缓存穿透缓存穿透不是只会出现在恶意攻击场景里日常业务中也经常遇到用户查询不存在的订单用户手动输入了一个错误的订单号或者订单已经被删除。恶意请求遍历 ID攻击者用脚本连续请求不存在的 ID比如 1、2、3……一直往后遍历造成大量无效查询。内部系统数据不一致调用方传入的 ID 超出了正常范围或者上游系统写入了一条脏数据。运营后台误操作管理端删除了一条业务数据但调用方还持有旧 ID短时间内不断重试。在这些场景下如果没有防护措施数据库就会白白承受大量无用查询。更麻烦的是如果查询本身就是慢 SQL比如对一个大表做全表扫描那么穿透请求很可能直接把数据库连接池打满。2. 缓存空值方案原理与隐患2.1 缓存空值的基本思路缓存空值的想法非常朴素既然数据库里没有这条数据那我就在 Redis 里也存一个“空标记”下次再来查这个 key发现缓存里是空值就直接返回不再查数据库。举个例子用户查询商品 ID10086数据库里没有这条记录。服务端把 keyproduct:10086valuenull 写入 Redis并设置一个较短的过期时间比如 60 秒。后续 60 秒内再有请求查询 ID10086直接命中 Redis 的空缓存返回“商品不存在”。代码如下public Product getProductById(Long id) { String cacheKey product: id; // 1. 先查缓存 String cacheValue redisTemplate.opsForValue().get(cacheKey); // 2. 缓存命中直接返回 if (cacheValue ! null) { // 这里需要判断是否为空标记 if (EMPTY.equals(cacheValue)) { return null; } return JSON.parseObject(cacheValue, Product.class); } // 3. 缓存未命中查数据库 Product product productMapper.selectById(id); // 4. 数据库也没查到缓存空值 if (product null) { redisTemplate.opsForValue().set(cacheKey, EMPTY, 60, TimeUnit.SECONDS); return null; } // 5. 查到数据写缓存 redisTemplate.opsForValue().set(cacheKey, JSON.toJSONString(product), 3600, TimeUnit.SECONDS); return product; }这段代码看起来没什么问题也能解决一部分穿透请求。但从工程角度看它有几个明显的短板。2.2 缓存空值的三大隐患隐患一无效 key 占用 Redis 内存如果一个攻击者恶意遍历 ID假设每秒生成一亿个不存在的 ID那么服务端就会在 Redis 里写入一亿个空缓存。即便每个 key 只占几十字节总体内存消耗也非常可观。更危险的是这些空缓存会不断写入新的 key可能导致 Redis 内存被占满进而触发内存淘汰策略把正常业务缓存挤掉。要缓解这个问题只能给空缓存设置较短的过期时间比如 30 到 60 秒。但这样一来攻击者可以等空缓存过期后再次发起穿透请求防护效果就会打折。隐患二空值语义不清晰数据库返回 null 可能有很多种含义数据不存在、数据尚未生成、数据被逻辑删除、调用方权限不足等。如果全部统一缓存为 EMPTY下游调用方就无法区分这些情况。举个实际案例某个订单系统里订单创建后需要异步处理处理完成前订单数据不存在。如果此时来了查询请求服务端把空值缓存了 5 分钟那么订单处理完成后的 5 分钟内用户查询到的仍然是“订单不存在”造成数据不一致。隐患三缓存与数据库的一致性变复杂正常缓存只要在更新数据时删除或更新缓存即可空缓存则要求业务在数据真正写入时主动删除对应的空标记。如果漏删就会出现数据已经存在、但缓存还返回空值的情况。很多团队在接入消息队列后数据更新是通过 Binlog 监听进行的空缓存的删除逻辑很容易被遗漏。2.3 为什么说“只用缓存空值”不够工程化单个缓存空值实现起来很简单但它只是个“补救手段”不算一个完整的防护方案。真正的问题是缓存空值本身无法判断哪些 key 是合法的、哪些 key 是恶意的。它只能把“每次穿透数据库”变成“每 60 秒穿透一次数据库”并没有从源头过滤掉无效请求。所以在中大型项目中更合理的做法是先用布隆过滤器做第一层拦截把不存在的 key 挡在门外再用缓存空值作为兜底处理那些通过布隆过滤器但数据库仍然没有数据的少数情况最后配合参数校验、限流和监控告警形成完整的防线。3. 布隆过滤器从源头拦截不存在的 key3.1 布隆过滤器是什么布隆过滤器是一种空间效率很高的概率型数据结构它可以告诉你“某个元素一定不存在”或者“某个元素可能存在”。注意这里的关键词可能存在。布隆过滤器不会漏报但会有一定的误判率。它的核心原理是初始化一个很长的二进制数组所有位都置为 0。插入元素时用多个哈希函数对元素计算哈希值得到多个数组下标把这些下标对应的位都置为 1。查询元素时同样计算多个哈希值检查这些下标对应的位是否都为 1。如果有一个位是 0说明元素一定不存在如果全部是 1说明元素可能存在因为可能有其他元素占用了这些位。用通俗的话解释布隆过滤器就像一张“大名单”你把所有已知的商品 ID 都登记上去。查询 ID 时如果名单里查不到那这个 ID 肯定不在名单里就不用去数据库了如果名单里查得到也不能完全确定它真实存在因为可能只是哈希碰撞导致的误判。3.2 用布隆过滤器解决缓存穿透使用方式是在缓存查询之前加一道过滤系统启动时把数据库中的所有商品 ID 加载到布隆过滤器里。请求进来后先用布隆过滤器判断 ID 是否存在。如果不存在直接返回不查缓存、不查数据库。如果存在继续走原有的缓存查询流程。这样的好处是大部分不存在的 ID 会在第一层被拦截数据库几乎不会被无效请求打到。相比缓存空值布隆过滤器不会往 Redis 里写入大量空 key内存占用更稳定。3.3 Redis 中的布隆过滤器实现布隆过滤器可以用 Redis 原生实现也可以使用 Redisson 封装好的 RBloomFilter。如果你使用的是 Redis 4.0 及以上版本还可以通过 RedisBloom 模块直接使用 BF.ADD、BF.EXISTS 等命令。下面是 Redisson 的使用示例Configuration public class BloomFilterConfig { Bean public RBloomFilterLong productBloomFilter(RedissonClient redissonClient) { RBloomFilterLong bloomFilter redissonClient.getBloomFilter(productBloomFilter); // 初始化布隆过滤器预计元素数量为 100000误判率为 0.01 bloomFilter.tryInit(100000L, 0.01); return bloomFilter; } }在业务代码中查询前先判断public Product getProductById(Long id) { // 1. 布隆过滤器拦截不存在的 ID if (!productBloomFilter.contains(id)) { return null; } // 2. 后续走正常的缓存查询逻辑 String cacheKey product: id; // ... }需要注意的是布隆过滤器对“新增数据”的响应有延迟。如果系统启动时只加载了存量 ID之后新创建的商品 ID 没有同步到布隆过滤器里就会出现“数据已存在但布隆过滤器判断不存在”的问题。因此生产环境需要在商品创建时同步更新布隆过滤器或者定期重建。3.4 布隆过滤器的局限性布隆过滤器不是万能的它有这几个问题无法删除元素标准的布隆过滤器不支持删除操作因为一个二进制位可能被多个元素共享。如果要删除需要使用 Counting Bloom Filter 变种。这意味着当商品 ID 被删除时布隆过滤器里依然保留它无法主动移除。有误判率布隆过滤器会把一部分不存在的元素判断为“可能存在”这些请求仍然会穿透到数据库。需要提前初始化如果没有提前加载全量数据就会出现误判为不存在的场景。正因为布隆过滤器存在这些局限它通常和缓存空值搭配使用而不是互相替代。4. 互斥锁与逻辑过期解决热点 key 场景4.1 互斥锁解决缓存击穿缓存穿透的一种极端情况是热点 key 过期。假设某个商品 ID 是真实存在的而且访问量极高那么在缓存过期的瞬间大量请求同时发现缓存没有数据会一起打到数据库。这种现象也叫缓存击穿可以理解为“单个 key 的穿透”。解决思路是加互斥锁在缓存未命中时只允许一个线程去查数据库并重建缓存其他线程等待缓存重建完成后再读取。Redis 中可以使用 SETNX 命令模拟分布式锁public Product getProductByIdWithLock(Long id) { String cacheKey product: id; String cacheValue redisTemplate.opsForValue().get(cacheKey); if (cacheValue ! null) { return JSON.parseObject(cacheValue, Product.class); } String lockKey lock:product: id; String requestId UUID.randomUUID().toString(); Boolean locked redisTemplate.opsForValue().setIfAbsent(lockKey, requestId, 3, TimeUnit.SECONDS); if (Boolean.TRUE.equals(locked)) { try { // 二次检查缓存防止等待期间缓存已被其他线程重建 cacheValue redisTemplate.opsForValue().get(cacheKey); if (cacheValue ! null) { return JSON.parseObject(cacheValue, Product.class); } Product product productMapper.selectById(id); if (product null) { // 这里可以配合缓存空值或布隆过滤器 return null; } redisTemplate.opsForValue().set(cacheKey, JSON.toJSONString(product), 3600, TimeUnit.SECONDS); return product; } finally { // 只删除自己加的锁避免误删其他线程的锁 String lockValue redisTemplate.opsForValue().get(lockKey); if (requestId.equals(lockValue)) { redisTemplate.delete(lockKey); } } } // 没有拿到锁休眠后重试 try { Thread.sleep(50); } catch (InterruptedException e) { Thread.currentThread().interrupt(); } return getProductByIdWithLock(id); }这段代码实现了互斥重建缓存的效果适合热点 key 的缓存击穿场景。但需要注意锁的粒度是每个商品 ID 一个锁不要把多个 key 共用一把锁否则会导致大量请求互相阻塞。4.2 逻辑过期方案逻辑过期是另一种解决缓存击穿的方式它的思路是缓存里不设置真正的过期时间而是在 value 中额外保存一个过期时间戳。查询时判断逻辑时间是否过期如果过期则尝试获取锁由拿到锁的线程异步重建缓存。逻辑过期方案的优点是查询请求不会被阻塞即使缓存已过期也能立刻返回旧数据缺点是实现复杂需要额外的过期时间字段而且可能短暂返回旧数据。public Product getProductByIdLogicExpire(Long id) { String cacheKey product: id; String cacheValue redisTemplate.opsForValue().get(cacheKey); if (cacheValue null) { // 缓存不存在可能是数据库没有该数据需要结合布隆过滤器判断 return null; } // 解析缓存内容 CacheDataProduct cacheData JSON.parseObject(cacheValue, new TypeReferenceCacheDataProduct() {}); long currentTime System.currentTimeMillis(); // 逻辑未过期直接返回 if (cacheData.getExpireTime() currentTime) { return cacheData.getData(); } // 逻辑过期获取锁后异步重建缓存 String lockKey lock:product: id; boolean locked redisTemplate.opsForValue().setIfAbsent(lockKey, 1, 3, TimeUnit.SECONDS); if (locked) { // 开启异步线程重建缓存 CompletableFuture.runAsync(() - { try { Product product productMapper.selectById(id); if (product ! null) { CacheDataProduct newCacheData new CacheData(product, System.currentTimeMillis() 3600 * 1000); redisTemplate.opsForValue().set(cacheKey, JSON.toJSONString(newCacheData)); } } finally { redisTemplate.delete(lockKey); } }); } // 先返回旧数据 return cacheData.getData(); }逻辑过期方案更贴近线上高并发场景但要注意线程池的隔离避免异步任务占满业务线程池。5. 请求参数校验与限流兜底5.1 参数合法性校验很多缓存穿透是由非法请求参数引起的。比如商品 ID 应该是正数但调用方传入了负数订单号应该符合特定格式但调用方传入了随机字符串。如果能在接口入口做一次参数校验很多无效请求根本不会进入缓存和数据库。使用 Spring Boot 的 Validation 注解可以简单实现GetMapping(/product/{id}) public Product getProduct(PathVariable Min(value 1, message 商品ID必须为正数) Long id) { return productService.getProductById(id); }除了参数范围校验还可以校验 ID 格式、请求签名、用户权限。对于内部服务之间的调用推荐在 API 网关层统一做基础校验业务服务内部再做一次完整校验。5.2 限流与降级即使有了布隆过滤器和参数校验仍然可能会出现突发流量。比如活动期间大量用户同时访问同一个商品或者调用方出现 Bug无限循环调用同一个接口。此时需要通过限流来保护数据库。常见的限流策略包括单机限流使用 Guava RateLimiter 或 Resilience4j分布式限流使用 Redis Lua 脚本实现令牌桶或滑动窗口。下面是基于 Redis 的简单限流示例public boolean tryAcquire(String key, int limit, int windowSeconds) { String luaScript local current redis.call(incr, KEYS[1]) if current 1 then redis.call(expire, KEYS[1], ARGV[1]) end if current tonumber(ARGV[2]) then return 0 else return 1 end; Long result redisTemplate.execute( new DefaultRedisScript(luaScript, Long.class), Collections.singletonList(key), windowSeconds, limit ); return Long.valueOf(1).equals(result); }限流不能完全避免缓存穿透但它能保证即使在最坏情况下数据库也不会被无限打爆是最后一道安全兜底。5.3 缓存空值与布隆过滤器的组合策略讲完各种方案后来梳理一下它们的关系参数校验是第一层拦截非法参数。布隆过滤器是第二层拦截绝大多数不存在的 ID。缓存空值是第三层兜住布隆过滤器误判之后仍然打到数据库的请求。互斥锁或逻辑过期是第四层解决热点 key 缓存过期后的击穿问题。限流是整个系统的最后防线。这四层不是必须全部实现而是要根据业务规模和请求特征选择。如果业务非常简单数据库压力不大只做参数校验和缓存空值就够了如果是高并发核心链路建议完整组合。6. 完整实战组合方案最小实现6.1 场景假设假设我们有一个商品查询接口要求商品 ID 必须为正整数。不存在的商品 ID 不会穿透数据库。热点商品缓存过期时数据库不会被打垮。空缓存只保留很短的时间避免占用过多内存。使用 Spring Boot Redis Redisson 实现。6.2 项目结构src/main/java/com/example/cache/ ├── CacheApplication.java ├── config/ │ ├── RedisConfig.java │ └── BloomFilterConfig.java ├── controller/ │ └── ProductController.java ├── service/ │ ├── ProductService.java │ └── ProductServiceImpl.java ├── mapper/ │ └── ProductMapper.java ├── entity/ │ └── Product.java └── common/ └── CacheData.java src/main/resources/ └── application.yml6.3 核心代码先看项目配置文件spring: data: redis: host: localhost port: 6379 timeout: 3000ms redisson: config: | singleServerConfig: address: redis://localhost:6379然后看一下布隆过滤器配置// 文件路径src/main/java/com/example/cache/config/BloomFilterConfig.java Configuration public class BloomFilterConfig { Bean public RBloomFilterLong productBloomFilter(RedissonClient redissonClient) { RBloomFilterLong bloomFilter redissonClient.getBloomFilter(productBloomFilter); // 预计数据量 100000误判率 1% bloomFilter.tryInit(100000L, 0.01); return bloomFilter; } }接下来是业务实现// 文件路径src/main/java/com/example/cache/service/ProductServiceImpl.java Service public class ProductServiceImpl implements ProductService { private static final String CACHE_KEY_PREFIX product:; private static final String EMPTY_VALUE EMPTY; private static final long EMPTY_TTL_SECONDS 30; private static final long NORMAL_TTL_SECONDS 3600; Autowired private RedisTemplateString, String redisTemplate; Autowired private ProductMapper productMapper; Autowired private RBloomFilterLong productBloomFilter; Override public Product getProductById(Long id) { // 第一层参数校验 if (id null || id 0) { throw new IllegalArgumentException(商品ID不合法); } // 第二层布隆过滤器拦截不存在的 ID if (!productBloomFilter.contains(id)) { return null; } String cacheKey CACHE_KEY_PREFIX id; // 第三层读取缓存 String cacheValue redisTemplate.opsForValue().get(cacheKey); if (cacheValue ! null) { if (EMPTY_VALUE.equals(cacheValue)) { return null; } return JSON.parseObject(cacheValue, Product.class); } // 第四层互斥锁解决缓存击穿 String lockKey lock: cacheKey; String requestId UUID.randomUUID().toString(); boolean locked Boolean.TRUE.equals( redisTemplate.opsForValue().setIfAbsent(lockKey, requestId, 3, TimeUnit.SECONDS) ); if (locked) { try { // 二次检查缓存 cacheValue redisTemplate.opsForValue().get(cacheKey); if (cacheValue ! null) { if (EMPTY_VALUE.equals(cacheValue)) { return null; } return JSON.parseObject(cacheValue, Product.class); } // 查询数据库 Product product productMapper.selectById(id); if (product null) { // 第五层缓存空值并设置较短 TTL redisTemplate.opsForValue().set(cacheKey, EMPTY_VALUE, EMPTY_TTL_SECONDS, TimeUnit.SECONDS); return null; } redisTemplate.opsForValue().set(cacheKey, JSON.toJSONString(product), NORMAL_TTL_SECONDS, TimeUnit.SECONDS); return product; } finally { // 释放锁只释放当前线程持有的锁 String lockValue redisTemplate.opsForValue().get(lockKey); if (requestId.equals(lockValue)) { redisTemplate.delete(lockKey); } } } // 未获取到锁休眠后重试 try { Thread.sleep(50); } catch (InterruptedException e) { Thread.currentThread().interrupt(); } return getProductById(id); } }这段代码把参数校验、布隆过滤器、缓存空值、互斥锁整合在了一起每一层的职责都很清晰。6.4 数据初始化系统启动后需要把所有存在的商品 ID 加载进布隆过滤器。可以通过 ApplicationRunner 实现// 文件路径src/main/java/com/example/cache/config/DataInitializer.java Component public class DataInitializer implements ApplicationRunner { Autowired private RBloomFilterLong productBloomFilter; Autowired private ProductMapper productMapper; Override public void run(ApplicationArguments args) { ListLong productIds productMapper.selectAllIds(); for (Long id : productIds) { productBloomFilter.add(id); } log.info(布隆过滤器初始化完成共加载 {} 个商品ID, productIds.size()); } }商品创建时也需要同步把新 ID 添加进布隆过滤器public void createProduct(Product product) { productMapper.insert(product); productBloomFilter.add(product.getId()); }6.5 运行与验证启动服务后可以用 curl 测试# 请求一个不存在的 ID观察是否直接返回 curl http://localhost:8080/product/99999 # 请求一个合法 ID curl http://localhost:8080/product/1在测试环境可以关闭布隆过滤器只保留缓存空值对比两种情况下数据库的查询次数能直观看到布隆过滤器的拦截效果。7. 常见问题与排查思路在实际使用缓存穿透防护方案时下面这些问题是出现频率较高的可以先收藏起来遇到类似情况时快速对照排查。问题现象常见原因解决思路布隆过滤器误杀正常数据新数据没有同步到布隆过滤器在数据创建时同步调用 add或定期重建过滤器缓存空值导致数据不一致空值 TTL 过长业务数据已写入但缓存仍返回空缩短空值 TTL数据写入时主动删除空缓存Redis 内存增长过快空缓存 key 过多没有设置合理的 TTL为不同场景设置不同的空值过期时间配合布隆过滤器热点 key 过期后数据库压力突增没有互斥锁或逻辑过期保护增加 SETNX 互斥锁或改用逻辑过期方案锁误删问题释放锁时没有校验持有者删除了其他线程的锁使用 requestId 校验只删除自己加的锁布隆过滤器误判率过高预计元素数量设置偏小或哈希函数数量不合适调大预计元素数量降低误判率或改用 Counting Bloom Filter异步重建缓存出现重复查询锁过期时间太短线程执行时间超过锁持有时间合理设置锁过期时间或使用 Redisson 的看门狗机制其中布隆过滤器的误杀问题在工程中尤其常见。很多团队只在启动时加载了一次数据后续新产生的数据没有及时加入过滤器导致新用户、新订单被误判为不存在。解决办法有两种一是在写入数据库的业务代码中同步更新布隆过滤器二是周期性重建布隆过滤器比如每 5 分钟把最近新增的数据重新加载一遍。另外缓存空值和布隆过滤器一起使用时要注意缓存 key 的规范。建议统一使用业务前缀加 ID 的格式比如 product:123并在缓存服务层面做好 key 的拆分和分类方便排查问题。8. 工程最佳实践与设计建议8.1 根据业务规模选择方案不是所有业务都需要完整组合布隆过滤器、互斥锁、限流。这里给出一个参考小型项目、内部管理系统数据库压力小使用参数校验 缓存空值即可空值 TTL 设置 30 到 60 秒。中型互联网项目推荐增加布隆过滤器解决大量不存在的 key 穿透问题同时配合缓存空值兜底。大型高并发核心链路在上述基础上增加互斥锁或逻辑过期、限流、监控告警形成完整防护体系。8.2 缓存空值的 TTL 设计如果决定使用缓存空值TTL 不宜太长也不宜太短。太长会导致数据不一致太短则防护效果有限。常见经验值普通业务空值30 到 60 秒。高频访问场景空值可以延长到 5 分钟但必须确保业务写入时能主动删除。动态生成数据的场景建议不缓存空值改用布隆过滤器结合延迟重试。8.3 监控与告警缓存穿透防护方案上线后要关注以下监控指标数据库慢查询数量如果穿透防护无效慢查询会明显上升。Redis 内存使用量如果空缓存没有及时回收内存曲线会持续上升。布隆过滤器误判率可以通过日志统计过滤后的请求数量。缓存命中率正常业务缓存命中率应该在 90% 以上异常下降时要排查。如果发现数据库查询量突然上升第一时间检查是哪些 key 导致的再确认是参数校验、布隆过滤器还是缓存空值没有生效。8.4 生产环境变更流程缓存防护方案涉及的配置和代码变更在生产环境要遵循最小权限和灰度发布原则先在测试环境压测模拟大量不存在的 ID 请求观察数据库连接数和响应时间。灰度一台机器观察监控指标是否正常。逐步放量确认没有数据一致性问题和内存异常增长。上线后持续观察 24 小时尤其是空缓存回收和布隆过滤器误判情况。8.5 团队规范最后是工程层面的建议。缓存穿透防护不是某个开发同学一个人的事团队里需要有统一约定明确空值缓存的 key 规范和使用场景避免不同模块各自为战。布隆过滤器的数据初始化逻辑必须放在应用的启动流程里而且要有日志输出加载数量。所有缓存查询的关键路径都要有 trace 日志便于排查链路问题。代码 Review 时重点检查锁的释放逻辑、空值缓存的删除逻辑和数据写入时布隆过滤器的同步逻辑。9. 总结与下一步方向“用缓存空值解决缓存穿透的都是初学者”这种说法虽然有些绝对但它提醒我们缓存空值只是缓存穿透防护体系中的一环不是银弹。真正的工程化方案是把参数校验、布隆过滤器、缓存空值、互斥锁、限流和监控组合起来让每一层各司其职。文中给出的组合示例是直接可运行的思路你可以把它改造成适合自己业务的形式。下一步建议重点学习 Redis 底层数据结构、Redisson 的分布式锁实现以及高并发场景下的缓存一致性保障。缓存穿透只是 Redis 使用中的一个经典问题后续还有缓存一致性、多级缓存、缓存热 key 发现等技术点都是深入掌握缓存体系的好方向。