缓存在高并发系统中是保护数据库的重要防线但实践中常会遇到三个棘手的现象缓存穿透、缓存击穿和缓存雪崩。理解它们的区别和应对方案是后端工程师的必修课。下面我就以一个电商商品查询场景为例结合代码逐一拆解。1. 缓存穿透是什么查询一个数据库和缓存中都不存在的数据。由于缓存没有命中每次请求都会穿透到数据库恶意攻击者可通过构造大量不存在的 ID 瞬间压垮数据库。举例商品 ID 自增攻击者并发请求productId -1此 ID 不可能存在。每次请求都绕过缓存直接访问数据库造成数据库查询压力激增。解决方案方案一缓存空对象当数据库查询结果为 null 时也将一个空值标识缓存起来并设置较短的过期时间如30秒。这样后续攻击请求会直接命中缓存不会到达数据库。public Product getProductById(Long productId) { String cacheKey product: productId; // 1.查缓存 Product product (Product) redisTemplate.opsForValue().get(cacheKey); if (product ! null) { return product; // 命中直接返回 } // 2.查数据库假设这里调用 productMapper.selectById product productMapper.selectById(productId); if (product ! null) { // 数据库有写入缓存过期1小时 redisTemplate.opsForValue().set(cacheKey, product, 1, TimeUnit.HOURS); } else { // 数据库没有缓存空对象过期30秒 redisTemplate.opsForValue().set(cacheKey, new Product(), 30, TimeUnit.SECONDS); } return product; }注意点空对象占用内存空间有限但要控制过期时间避免长期存在。若空值也有业务含义可缓存一个特殊标记对象如NullProduct。方案二布隆过滤器维护一个存储所有合法 key 的布隆过滤器请求先经过布隆过滤器判定如果认为不存在则直接返回不再查询缓存和数据库。这种方式内存占用小但存在误判率判定不存在时一定不存在判定存在时可能不存在。适合数据量极大的场景。// 初始化布隆过滤器使用 Guava 库 BloomFilterLong bloomFilter BloomFilter.create( Funnels.longFunnel(), 1000000, // 预计数据量 0.01); // 误判率 // 查询时先判断 if (!bloomFilter.mightContain(productId)) { return null; // 直接返回避免穿透 } // 后续走缓存-数据库流程...生产上常用 Redisson 的布隆过滤器或 Redis 插件来实现分布式布隆过滤器。2. 缓存击穿是什么某个热点数据如秒杀商品缓存恰好过期此时大量并发请求同时查询该 key因缓存失效所有请求瞬间打到数据库导致数据库瞬时压力过大。举例爆款手机缓存 key 在 12:00:00 过期恰逢促销活动每秒上万请求涌入同一时刻发现缓存为空全部穿透到数据库数据库 CPU 直接 100%。解决方案核心思路保证同一个 key 同一时刻只有一个线程去加载数据其他线程等待或快速失败。方案一互斥锁分布式锁使用 Redis 的SETNX或 Redisson 的分布式锁实现互斥。public Product getProductWithLock(Long productId) { String cacheKey product: productId; Product product (Product) redisTemplate.opsForValue().get(cacheKey); if (product ! null) { return product; } // 获取分布式锁锁的key lock:product: productId RLock lock redissonClient.getLock(lock:product: productId); try { // 尝试加锁等待5秒锁有效期30秒 if (lock.tryLock(5, 30, TimeUnit.SECONDS)) { // 双重检查避免锁内再次查缓存 product (Product) redisTemplate.opsForValue().get(cacheKey); if (product ! null) { return product; } // 查数据库 product productMapper.selectById(productId); if (product ! null) { redisTemplate.opsForValue().set(cacheKey, product, 1, TimeUnit.HOURS); } else { // 缓存空对象防止穿透 redisTemplate.opsForValue().set(cacheKey, new Product(), 30, TimeUnit.SECONDS); } } else { // 获取锁失败可快速失败或自旋等待后重试 Thread.sleep(50); return getProductWithLock(productId); // 递归重试 } } catch (InterruptedException e) { Thread.currentThread().interrupt(); } finally { lock.unlock(); } return product; }方案二逻辑过期 异步刷新不设置物理过期时间TTL在 value 中存储一个逻辑过期时间字段。读取时若发现逻辑时间已过期返回旧值的同时异步更新缓存。这样永远不出现缓存失效瞬间的并发穿透。// 存储实体内部包含数据和过期时间戳 public class ProductWrapper { private Product product; private long expireTime; // 逻辑过期时间戳 } public Product getProductLogicalExpire(Long productId) { String cacheKey product: productId; ProductWrapper wrapper (ProductWrapper) redisTemplate.opsForValue().get(cacheKey); if (wrapper null) { // 缓存不存在直接查库并写入可能是冷数据并发不高 Product product productMapper.selectById(productId); wrapper new ProductWrapper(product, System.currentTimeMillis() 3600_000); redisTemplate.opsForValue().set(cacheKey, wrapper); return product; } if (wrapper.getExpireTime() System.currentTimeMillis()) { return wrapper.getProduct(); // 未过期直接返回 } // 逻辑过期尝试获取锁进行异步刷新 String lockKey lock:product: productId; boolean locked redisTemplate.opsForValue().setIfAbsent(lockKey, 1, 10, TimeUnit.SECONDS); if (locked) { // 异步更新缓存 executorService.submit(() - { Product product productMapper.selectById(productId); ProductWrapper newWrapper new ProductWrapper(product, System.currentTimeMillis() 3600_000); redisTemplate.opsForValue().set(cacheKey, newWrapper); redisTemplate.delete(lockKey); }); } // 返回旧数据即使过期也先用着 return wrapper.getProduct(); }3. 缓存雪崩是什么同一时刻大量缓存 key 同时过期或缓存服务器宕机导致海量请求直接访问数据库数据库不堪重负甚至引发连锁崩溃。举例某整点活动所有商品缓存同时设置了1小时过期。恰好在活动高峰时大量 key 集中失效数据库瞬间瘫痪。解决方案方案一过期时间加随机值在原有过期时间上追加一个随机秒数避免集中过期。// 设置缓存时基础过期时间随机偏移 int baseExpireSeconds 3600; // 1小时 int randomSeconds new Random().nextInt(600); // 0~600秒随机 redisTemplate.opsForValue().set(cacheKey, product, baseExpireSeconds randomSeconds, TimeUnit.SECONDS);方案二高可用架构对 Redis 使用主从哨兵或集群模式避免单点宕机。缓存层做好故障转移和自动恢复。方案三多级缓存 限流降级在应用本地增加一层 Caffeine 缓存或使用 Nginx 本地缓存。当 Redis 不可用时请求优先走本地缓存。同时引入 Hystrix / Sentinel 限流防止数据库被打死。// 使用 Caffeine 作为一级缓存Redis 为二级 CacheLong, Product localCache Caffeine.newBuilder() .expireAfterWrite(5, TimeUnit.MINUTES) .maximumSize(10000) .build(); public Product getProductMultiLevel(Long productId) { // 1. 查本地缓存 Product product localCache.getIfPresent(productId); if (product ! null) return product; // 2. 查 Redis product (Product) redisTemplate.opsForValue().get(product: productId); if (product ! null) { localCache.put(productId, product); return product; } // 3. 查数据库加锁防击穿此处省略 // ... return product; }三者对比总结现象原因核心解法穿透查询不存在的数据缓存空对象 / 布隆过滤器击穿热点 key 过期并发查库互斥锁 / 逻辑过期异步刷新雪崩大量 key 同时过期或服务宕机过期时间随机化 / 高可用 / 多级缓存实际开发中三种策略往往组合使用。例如商品查询接口同时采用布隆过滤器防穿透分布式锁防击穿过期时间随机化防雪崩。理解它们的本质才能在高并发场景下设计出稳定的缓存体系。