获课：jzit.top/24319/

缓存三剑客：穿透、击穿、雪崩的实战攻防手册

任何一个经历过线上高并发的Java工程师，恐怕都忘不了那个凌晨被报警电话叫醒的夜晚：数据库CPU飙到90%，响应时间从50ms飙升到2秒，部分请求直接500错误。事后复盘，根因往往不是慢SQL，而是缓存层在某个瞬间集体失灵了——要么是恶意用户用不存在的ID不停穿透，要么是一个爆款商品的热点Key恰好在流量峰值时过期，要么是运维把所有缓存Key设成了同一个过期时间，到点一起失效。这三个场景，就是Java工程师必须啃下的“缓存三剑客”：穿透、击穿、雪崩。

缓存穿透：挡不住“不存在”的恶意请求

缓存穿透，指查询的是缓存和数据库中都不存在的数据，这类请求会绕过缓存直接打到数据库。典型的案例是攻击者构造大量不存在的用户ID（如/api/user/-1、/api/user/-2）持续发起请求，缓存查不到，数据库也查不到，每次都白白回源一次，最终耗尽数据库连接资源。

解决穿透问题，最朴素但有效的方法是缓存空对象：当从数据库查询结果为空时，也将这个空结果缓存起来，设置较短的过期时间（如60秒），下次同样Key的请求就能命中缓存，不再穿透到数据库。这个方法实现简单，但当Key空间无限大时（比如攻击者每次用随机ID），空值缓存会占用大量内存。

更工程化的方案是布隆过滤器（Bloom Filter）。系统启动时将全部合法ID预先“灌”入布隆过滤器，每次查询前先用布隆过滤器判断Key是否存在，不存在的Key直接拦截返回，连缓存都不用查。布隆过滤器本质是一个位图加若干哈希函数，用一个极小内存（百万级数据约需1.2MB）就能承载海量判断，虽然存在极小概率的误判，但对于缓存防护场景完全可接受——误判只是多查一次缓存和数据库，不会造成穿透。如果有条件，在接口层增加参数校验和用户鉴权，也能从入口过滤掉大量非法请求。

缓存击穿：单个热点Key的“致命过期”

缓存击穿和穿透最大的区别是：击穿场景中，那个Key是真实存在的，只是恰好在某一瞬间过期了。比如一个PV千万级的爆款商品详情页，缓存过期那100毫秒内涌进两万个并发请求，两万个线程同时发现缓存没数据，一起涌向数据库，连接池瞬间被占满。这是一个“单点爆破”型问题。

应对击穿，业界有两条主路，对应不同的业务需求。

第一条路是互斥锁（分布式锁）。在查询缓存未命中时，先尝试获取分布式锁（如Redis的SET NX EX），抢到锁的线程去查询数据库并重建缓存，没抢到的线程短暂等待或休眠重试，直到缓存重建完成。这种方案能保证数据的强一致性，但会牺牲部分性能——高并发下锁的竞争压力较大。

第二条路是逻辑过期（永不过期）。缓存Key本身在Redis中不设TTL，但数据对象中自带一个expireAt字段。读取时先返回缓存中的旧数据，后台异步检查是否到期，到期则另起线程去刷新缓存。这个方案的好处是缓存永远不会真正未命中，用户体验几乎不受影响，但代价是会读到短时间的旧数据，数据一致性较弱。在金钱交易等强一致场景选互斥锁，在互联网高并发体验优先的场景选逻辑过期，这是工程师必须做的权衡。

缓存雪崩：大规模Key同时失效的“全面崩塌”

如果说击穿是“单点爆破”，雪崩就是“全面崩塌”：大量Key在同一时间点集体失效，或者Redis实例整体宕机，导致海量请求瞬间直击数据库，引发级联故障。

造成雪崩最常见的原因是过期时间设置不当——比如批量导入数据时给所有Key统一设置了30分钟过期时间，到点一起失效。解决方案是在设置过期时间时引入随机因素：在原有过期时间基础上增加1-5分钟的随机值，让Key的失效时间分散开来，避免“齐刷刷”地过期。

另一类雪崩原因是Redis服务宕机，这时需要从架构层保障：搭建Redis高可用集群（主从复制、哨兵或Cluster模式），确保单节点故障后能快速切换，不会让整个缓存层“失声”。同时，可以引入多级缓存架构——在Redis之上再加一层本地缓存（如Caffeine），即使Redis短时不可用，本地缓存仍能挡住部分请求，为恢复争取时间。最后，限流降级是兜底方案：当检测到数据库压力过大时，对非核心业务请求直接拒绝或返回默认值，优先保障核心功能。

结语

穿透、击穿、雪崩这三个问题，本质上都是“缓存层失去挡墙作用”时的不同表现形式。理解它们的区别——穿透是“数据压根不存在”，击穿是“单个热点失效”，雪崩是“大量Key同时失效”——才能对症下药。对于一个Java工程师来说，掌握布隆过滤器、互斥锁、逻辑过期、随机过期时间、多级缓存、限流降级这一整套工具链，不是为了炫技，而是为了在每一个流量洪峰到来时，让数据库活下来，让系统撑得住。