当前位置：首页 > news >正文

分布式锁的七种写法：从 SetNX 到 Redisson 看门狗 (WatchDog)，谁才是最终答案？

news 2026/7/3 18:27:38

🔒 前言：面试官的陷阱

“请手写一个 Redis 分布式锁。”
如果你直接写了redis.setnx(key, 1)，面试官可能会让你直接回家等通知。

为什么？

如果服务器宕机，锁没释放怎么办？（死锁）
如果你加了过期时间，但业务执行时间超长怎么办？（锁失效）
如果你释放了别人的锁怎么办？（并发安全）

今天，我们像剥洋葱一样，从青铜到王者，拆解分布式锁的7 种进化形态。

👶 第一阶段：青铜时代 (漏洞百出)

写法一：裸奔的`setnx`

// 1. 抢锁if(redis.setnx(lockKey,1)==1){try{// 业务逻辑...}finally{// 2. 释放锁redis.del(lockKey);}}

致命死穴：如果业务逻辑执行到一半，服务器宕机了/重启了，finally没执行，锁永远删不掉。造成永久死锁！

写法二：`setnx`+`expire`

if(redis.setnx(lockKey,1)==1){redis.expire(lockKey,30);// 补一个过期时间try{...}finally{redis.del(lockKey);}}

致命死穴：setnx和expire是两条命令，不是原子的。如果刚 setnx 完，网线被拔了，expire 没执行，依然死锁！

🥈 第二阶段：白银时代 (原子性解决)

写法三：`SET NX PX`(Redis 2.6.12+)

Redis 官方终于看不下去了，把设置值和过期时间合并成了一条命令。

// 原子命令：SET lockKey requestId NX PX 30000Stringresult=jedis.set(lockKey,requestId,"NX","PX",30000);if("OK".equals(result)){try{...}finally{redis.del(lockKey);}}

潜在问题：解决了死锁，但还有一个大坑——误删锁。
1. A 拿到锁，过期时间 30s。
2. A 业务卡顿，跑了 40s。此时锁自动过期，B 拿到了锁。
3. A 跑完了，执行finally里的del，把 B 的锁给删了！
4. C 趁虚而入，B 和 C 同时在跑，线程不安全。

写法四：UUID + Lua 脚本 (校验身份)

为了防止删错锁，我们在 Value 里存一个 UUID (Client ID)。删除前判断一下：这是不是我的锁？

-- Lua 脚本保证原子性ifredis.call('get',KEYS[1])==ARGV[1]thenreturnredis.call('del',KEYS[1])elsereturn0end

依然痛点：虽然不删别人的锁了，但 A 的业务还没跑完锁就过期了，A 依然是在“裸奔”（并发执行）。我们需要**“锁续期”**。

🥇 第三阶段：黄金时代 (Redisson 看门狗)

写法五：手动写守护线程 (太累)

你自己写一个 Timer，每隔 10秒检查一下，如果 A 还在跑，就给锁续命。
但是，写好这个多线程逻辑极其复杂，很容易由“解决死锁”变成“制造死锁”。

写法六：Redisson (工业级标准)

Redisson是 Redis 官方推荐的 Java 客户端，它内置了一个神器——看门狗 (WatchDog)。

使用代码（极其优雅）：

RLocklock=redisson.getLock("myLock");try{// 1. 加锁 (默认 30s 过期，自动启动看门狗)lock.lock();// 2. 业务逻辑 (哪怕跑 1 小时，锁也不会断)Thread.sleep(60*60*1000);}finally{// 3. 解锁 (自动停止看门狗)lock.unlock();}

看门狗原理图解：

WatchDog 核心逻辑：

Redisson 只要加锁成功，就会启动一个后台定时任务（TimeTask）。
默认每隔10秒(默认过期时间 30s 的 1/3) 检查一次。
如果当前线程还持有锁，就通过 Lua 脚本把 Redis 里的过期时间重置为 30s。
如果服务器宕机，看门狗线程也挂了，没人续期，Redis 里的锁 30s 后自动失效，不会死锁。完美！

👑 第四阶段：王者时代 (RedLock 红锁)

写法七：RedLock (解决主从一致性)

场景：

A 在 Redis Master 拿到了锁。
Master 还没来得及把数据同步给 Slave，Master 挂了。
Slave 升级为 New Master。
B 在 New Master 也可以拿到锁。
结果：A 和 B 同时持锁。

为了解决这个极端问题（虽然概率极低），Redisson 实现了RedLock算法。

原理：搞 5 个独立的 Redis 节点（不是集群，没有主从）。
规则：客户端同时向这 5 个节点申请锁，只要N/2 + 1 (即 3 个)节点加锁成功，就认为获取锁成功。

RLocklock1=redisson1.getLock("lock");RLocklock2=redisson2.getLock("lock");RLocklock3=redisson3.getLock("lock");RedissonRedLocklock=newRedissonRedLock(lock1,lock2,lock3);lock.lock();