Redis 5.0 本身不导致缓存击穿，但其 SET NX EX 原子加锁易被误用于缓存重建，因缺乏client_id校验、解锁非原子、无双重检查，放大击穿风险。
Redis 5.0 本身不会“导致”缓存击穿，但它的默认锁实现（SET NX EX）在高并发+热点数据过期场景下，极易放大击穿风险——这不是版本缺陷，而是设计边界没被正视。
缓存击穿在 Redis 5.0 中为何更显性
Redis 5.0 引入了 SET 命令的原子性参数（NX、EX），让加锁变简单，但很多人直接用它做“缓存重建锁”，却忽略了三个关键断层：
-
SET NX EX只管加锁，不保证锁释放和缓存写入的原子性：业务线程拿到锁后查 DB、写缓存、再删锁，中间任意一步失败（如网络抖动、GC停顿、进程崩溃），锁就丢了，但缓存仍为空，后续请求全打库 - 过期时间硬编码（如
EX 30）无法适配实际重建耗时：DB响应慢时，锁提前过期，多个线程同时重建缓存，不仅击穿，还可能写入脏数据 - 没有锁续约机制：Redis 5.0 原生命令不支持自动延长锁有效期，而长锁又违背“快速释放”原则，陷入两难
为什么不能只靠 try-finally + DEL 修复
这是 Redis 4.0 就流行的“补丁式”方案，但在 5.0 环境下依然脆弱：
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
-
DEL操作不是原子的：如果线程 A 加锁成功，执行完业务逻辑准备DEL时恰好锁过期，此时线程 B 已抢到新锁，A 的DEL会误删 B 的锁 → 后续请求全部击穿 - 没有客户端标识校验：
DEL不知道这个 key 是谁设的，只要 key 存在就删，根本无法区分“自己的锁”和“别人的锁” - 异常分支覆盖不全：比如
finally块里发生 OOM 或线程中断，DEL根本不会执行，锁永久残留（虽有超时，但已造成窗口期混乱）
升级方案必须解决的三个硬约束
真正能收敛击穿风险的升级，不是换工具，而是补足语义缺失：
- 加锁 + 设置唯一 client_id（如 UUID） + 过期时间，三者必须原子：推荐用
EVAL执行 Lua 脚本，Redis 5.0 完全支持，且脚本内所有操作在服务端串行执行 - 解锁必须校验 client_id：用 Lua 判断
GET出来的 value 是否匹配当前 client_id，再执行DEL，避免误删（Redisson 的unlockInnerAsync底层就是这逻辑） - 业务层需配合“双重检查”：先查缓存 → 缓存空则尝试加锁 → 加锁成功才查 DB 写缓存 → 加锁失败则短暂休眠后重试，而不是无脑轮询
最易被忽略的一点：Redis 5.0 的 SET 命令虽支持 NX EX，但它不解决“锁持有者身份可信”问题。任何把锁当成单纯 key 存在、不绑定上下文身份的方案，在分布式环境下都只是纸糊的防线。
