获课：xingkeit.top/5702/

Redis三大缓存故障：击穿、穿透、雪崩的完整攻防手册

在高并发系统中，Redis不是银弹，而是一颗随时可能炸膛的雷。击穿、穿透、雪崩——这三个名字听起来文艺，实际上每一个都能让你的数据库在几秒内崩溃。搞清楚它们的本质差异，才能对症下药。

一、穿透：有人在敲你家根本不存在的门

本质：查询的数据在缓存和数据库中都不存在，每次请求都直抵数据库。 攻击者构造大量非法ID疯狂请求，或者业务逻辑漏洞导致查询了已删除的数据。数据库连接池被迅速耗尽，正常请求也无法响应。

三道防线缺一不可：

第一道，参数校验。用户ID必须是正整数，商品ID必须在合法范围内，非法参数在入口就拦截，别让它碰到Redis。

第二道，布隆过滤器。用一个位数组加多个哈希函数，提前把所有合法ID加载进去。请求到来时先过过滤器——它说不存在，那就一定不存在；它说可能存在，才放行到Redis和数据库。误判率可控制在0.01%以下，空间开销极低，是穿透问题的终极屏障。

第三道，缓存空值。数据库查不到的数据，往Redis里写一个空标记，设置5分钟过期。后续相同请求直接返回空，不再穿透到数据库。但空值必须设短过期时间，否则数据库新增数据后，缓存里还是空值，就成了脏数据。

二、击穿：你家最火的那扇门突然坏了

本质：单个热点Key过期的瞬间，大量并发请求同时发现缓存失效，全部涌向数据库。 注意，击穿是"一个Key"的问题，不是一片Key。秒杀商品库存、热搜排行榜、爆款商品详情，都是重灾区。

核心策略：让同一时刻只有一个请求去重建缓存。

互斥锁是最通用的方案。缓存未命中时，用分布式锁（Redisson或Redis SETNX）抢锁，抢到的去查数据库并回写缓存，其他请求等待或返回旧数据。关键细节：必须二次检查缓存——锁等待期间，可能已有其他线程完成了重建。锁还要设超时时间，防止死锁。

更优雅的做法是"逻辑永不过期"。缓存数据里内嵌一个过期时间戳，每次访问时检查，若快过期了，启动异步线程去更新缓存，当前请求仍返回旧值。这样既避免了缓存失效的瞬间冲击，又保证了数据最终一致性。

三、雪崩：你家所有的门同时坏了

本质：大量Key在同一时间集体过期，或者Redis集群整体宕机，所有请求瞬间砸向数据库。 雪崩的破坏力远超击穿，因为它是全局性的。

根治方案从过期时间开始。 每个Key的过期时间必须加上随机偏移量——基础1小时过期，实际设1到2小时之间的随机值。这样即使百万Key同时写入，过期时刻也被打散到两小时的窗口内，不会形成尖峰。

多级缓存是雪崩的终极防线。 本地缓存（Caffeine）扛最热的那一层，Redis扛温数据，数据库只兜底。本地缓存天然将同一Key的请求分散到不同应用节点，Redis QPS可下降60%以上。某短视频平台实测：部署热点探测系统后，Redis节点QPS从20万降至几乎为零，接口响应从200毫秒压到15毫秒。

熔断降级是最后的保命符。 当数据库连接数超过阈值，Sentinel或Resilience4j自动熔断，直接返回兜底数据，而不是让整个链路一起死。

选型决策

三个问题的本质都是"缓存失效后流量过载"，但触发点和影响面完全不同。穿透防的是"不该来的请求"，击穿防的是"不该同时来的请求"，雪崩防的是"不该同时失效的缓存"。把这三层防御叠满，Redis才能真正成为你架构里的盾牌，而不是定时炸弹。