多节点部署项目 Redisson 来做分布式锁

情况一：锁设置了过期时间（最佳实践）—— 会自动释放
这是正确使用Redis分布式锁的方式。

•
流程：

1.
节点1 使用类似 SET lock_key unique_value NX PX 30000的命令获取锁。这个命令的含义是：如果键 lock_key不存在（NX），就设置它，值为一个唯一标识（如UUID），并设置一个30秒的过期时间（PX 30000）。

2.
节点1 获取锁成功，开始执行业务逻辑。

3.
在执行业务逻辑过程中，节点1 的服务器突然宕机。

4.
由于锁有30秒的过期时间，在30秒后，这个锁会被Redis自动删除（释放）。

5.
节点2 在尝试获取锁时，如果锁已自动释放，它就能成功获取到锁，并继续执行任务。

•
结论：在这种场景下，即使持有锁的节点挂了，锁也会在过期时间后自动释放，避免了死锁，保证了系统的高可用性。这是你必须使用的方案。

情况二：锁没有设置过期时间 —— 不会自动释放，导致死锁
这是一种非常错误且危险的使用方式。

•
流程：

1.
节点1 使用一个简单的 SETNX lock_key命令获取锁，但没有设置过期时间。

2.
节点1 获取锁成功，开始执行一个非常耗时的任务。

3.
任务执行中，节点1 宕机。

4.
因为这个锁没有过期时间，它会永久存在于Redis中。

5.
节点2 再来尝试获取锁时，会发现锁一直被节点1 占用着，永远无法成功。这就是 死锁。整个系统会因为这把锁而瘫痪。

•
结论：绝对不要使用不设置过期时间的分布式锁。

进阶话题：锁的续期（Watch Dog）
你可能会想到一个问题：如果业务逻辑的执行时间不确定，可能超过设置的过期时间怎么办？比如锁的过期时间是30秒，但业务逻辑执行了40秒。

•
问题：节点1还在正常运行，但锁在30秒时过期了。节点2在31秒时成功获取了锁。此时系统中就有两个节点同时持有同一把锁，导致数据错乱。

•
解决方案：锁续期（Watch Dog Mechanism）

成熟的分布式锁客户端（如Redisson）都实现了这个功能。其原理是：

1.
节点1获取锁时，会设置一个过期时间（例如30秒）。

2.
同时，客户端会启动一个后台线程（看门狗），这个线程会定期（比如在锁过期时间的1/3时，即10秒后）去检查节点1是否还持有锁。

3.
如果节点1的业务逻辑还在执行（即客户端还活着），看门狗就会通过Redis命令重置锁的过期时间（重新设置为30秒），这就是 “续期”。

4.
如果节点1挂了，看门狗线程也会随之停止，自然也就无法续期。锁最终还是会因为过期而被自动释放。

所以，在节点1挂掉的情况下：

•
如果使用了看门狗，看门狗线程停止，锁会在设定的过期时间后自动释放。

•
如果没有使用看门狗，但只要设置了过期时间，锁同样会在过期时间后自动释放。