Redis高并发分布式锁防缓存击穿方法

在高并发场景下，Redis缓存击穿是热点数据失效时大量请求直击数据库的致命风险，而简单使用SETNX加锁极易因非原子操作导致死锁或误删他人锁；本文深入剖析了分布式锁的核心陷阱与工程级解决方案：通过SET+NX+EX原子建锁、Lua脚本安全删锁、加锁后二次校验缓存、可控重试机制（而非死等）、以及针对高读低写场景的逻辑过期+异步刷新策略，不仅规避了经典误区，更强调锁生命周期管理这一真正难点——超时设置、自动续期、失败兜底等细节，才是保障系统稳定与性能的关键所在。

为什么直接用 SETNX 容易误删锁

很多同学一上来就写 SETNX lock:product:123 1，再配个 EXPIRE 分两步设锁，但这是错的。Redis 的命令不是原子的，中间若服务宕机或网络中断，锁可能只有 key 没有过期时间，变成永久死锁。更危险的是释放锁时直接 DEL lock:product:123 —— 如果线程 A 拿到锁后执行慢，超时自动释放，线程 B 又拿到了新锁，此时 A 才执行完并 DEL，就把 B 的锁给删了。

正确做法是用原子命令：SET lock:product:123 "uuid-abc" EX 30 NX，其中 "uuid-abc" 是当前线程唯一标识；释放锁必须先 GET 判断值匹配，再 DEL，且这两步需用 Lua 脚本保证原子性。

加锁后一定要 double-check 缓存

拿到锁不等于缓存一定为空。因为锁等待期间，其他线程可能已更新缓存。所以加锁成功后，必须再次 GET 一次缓存，确认仍为空才查库。

• 第一次 GET 缓存为空 → 尝试加锁
• 加锁成功 → 再次 GET 缓存（防止锁等待时已被更新）
• 若仍为空 → 查库、写缓存、释放锁
• 若已有值 → 直接返回，跳过查库

tryLock + 休眠重试比死等更实用

分布式环境下不能像单机那样用 synchronized 一直阻塞。应该设置明确的获取锁超时（如 100ms）和重试次数（如 3 次），避免线程长时间挂起。

常见错误是拿到锁失败就立刻 sleep(50) 然后递归调用自己，容易引发栈溢出或雪崩式重试。推荐写成循环：

• 最多尝试 3 次获取锁
• 每次失败后 Thread.sleep(50)
• 超过次数直接返回空或抛异常，由上层降级处理

逻辑过期比物理过期更适合高读低写热点

对秒杀商品详情这类数据，用“永不过期 + 逻辑过期字段”比纯互斥锁更平滑。缓存 value 存成 JSON：{"data": {...}, "expireAt": 1745172000000}，每次读取先判断 expireAt 是否过期。

过期后不阻塞，而是用线程池异步刷新，当前请求仍返回旧值。这样既防击穿，又不拖慢响应速度。但要注意：异步任务必须带重试和失败告警，否则脏数据会一直存在。

真正难的不是加锁，而是锁的生命周期管理 —— 锁该设多长？谁来续期？异步更新失败怎么兜底？这些细节没对齐，锁反而会成为系统瓶颈点。

到这里，我们也就讲完了《Redis高并发分布式锁防缓存击穿方法》的内容了。个人认为，基础知识的学习和巩固，是为了更好的将其运用到项目中，欢迎关注golang学习网公众号，带你了解更多关于的知识点！