为什么Redis 5.0版本容易出现击穿问题_升级分布式锁方案的必要性-Redis-PHP中文网

redis 5.0 本身不导致缓存击穿，但其 set nx ex 原子加锁易被误用于缓存重建，因缺乏client_id校验、解锁非原子、无双重检查，放大击穿风险。

为什么redis 5.0版本容易出现击穿问题_升级分布式锁方案的必要性

Redis 5.0 本身不会“导致”缓存击穿，但它的默认锁实现（SET NX EX）在高并发+热点数据过期场景下，极易放大击穿风险——这不是版本缺陷，而是设计边界没被正视。

Redis 5.0 引入了 SET 命令的原子性参数（NX、EX），让加锁变简单，但很多人直接用它做“缓存重建锁”，却忽略了三个关键断层：

SET NX EX 只管加锁，不保证锁释放和缓存写入的原子性：业务线程拿到锁后查 DB、写缓存、再删锁，中间任意一步失败（如网络抖动、GC停顿、进程崩溃），锁就丢了，但缓存仍为空，后续请求全打库
过期时间硬编码（如 EX 30）无法适配实际重建耗时：DB响应慢时，锁提前过期，多个线程同时重建缓存，不仅击穿，还可能写入脏数据
没有锁续约机制：Redis 5.0 原生命令不支持自动延长锁有效期，而长锁又违背“快速释放”原则，陷入两难

这是 Redis 4.0 就流行的“补丁式”方案，但在 5.0 环境下依然脆弱：

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 存在、不绑定上下文身份的方案，在分布式环境下都只是纸糊的防线。