分布式锁的一些细节问题，值得收藏

聊聊后端面试那些事

原文

分布式锁问题-【公粽号：堆栈future】

我看在技术大群里面有人问分布式锁问题，说是被面试官各种刁难，我是实在看不下去了，面试官意思很明确，你们有造火箭的经验吗，有的话来他们公司造自行车，没有的话：今天面试就到这里了！

但是说实话面试官没必要因为这个问题继续追问，没啥意思，但是又不得不问，确实有些企业用到分布式锁了。

没办法，逼迫你必须得背会它。

接下来就说下群友面试碰到的问题，因为候选人可能自己已经掌握了实现分布式锁的原理，但是被面试官问到细节可能就不清楚了，因此给大家讲下这块。

1. setnx+expire+del

问题-1 如果setnx执行成功，但是在expire执行的时候redis节点宕机了，在这种情况下，锁不会被释放，导致死锁。解决方案：

可以用SET EX PX NX替换setnx+expire
也可以用lua脚本保持原子操作。

问题-2 如果expire时间过短，但是任务执行时间过长，那么锁会因为过期而被删除，其它客户端可以重新获取锁。在这种情况下，多个客户端同时获取到了锁。解决方案：

过期时间足够长，保证任务可以完成。
启动一个守护线程，为即将到期但尚未释放的锁添加时间。
redission

问题-3 如果expire刚好过期，此时删除了这个key，那么当另一个客户端进行获取锁的时候就会抢到锁，那么这个时候当前释放锁的客户端会执行最后的del命令把别的客户端刚才设置的删除了，这个时候就破坏了资源的并发操作。

解决方案：

在这种情况下，我们需要检查正在被删除的锁是否与我们之前获得的锁相同。我们可以在设置它时使用唯一的值，例如直接使用UUID。这样，在删除锁时，我们需要获取锁的对应值，然后与当前节点对象的值进行比较，才能删除锁。

1. uuid = gen()
2. set key uuid ex 5 nx
3. 处理业务逻辑
4. valUUID = get key
5. if valUUID == uuid {delete key} else return

问题-4 假如redis主节点宕机，主从同步延迟或者有问题，那么从成为主之后，客户端就会重新获取到锁，这样也会并发不安全。解决方案：

redlock

问题-5 如果redis发生脑裂，那么也会发生多个客户端并发持有多个锁的问题，所以redis为了解决这个脑裂问题，引入两个配置，只有合理配置这两个参数就可以尽最大努力避免脑裂，细节大家下去自行研究哈。

min-slaves-to-write
min-slaves-max-lag

2. redission

锁过期，但是任务还没执行完成，只需将锁过期时间设置长一点即可。比如拿到锁的线程，开启一个定时的守护线程，每隔一段时间检查一下锁是否还存在，如果存在就延长锁的过期时间，防止锁过期和提前释放。Redisson的底层原理图：只要线程成功获取到锁，就会启动一个watch dog，它是一个后台线程，每10秒检查一次，如果线程一持有锁，那么它会不断延长锁的生存时间。因此，Redisson是可以解决过期时间到了但是业务还没执行完的问题。

3. redlock

Redlock核心思想是这样的：部署多个redis master节点，确保它们不会同时宕机。而且这些主节点之间是完全独立的，它们之间没有数据同步。同时，我们需要确保使用相同的方法来获取和释放锁。具体获取锁和释放锁的步骤大家下去自行研究。

这个redlock主要是解决一个线程在redis的master节点上持有锁，但是 locked key并没有同步到从节点。就在这时，主节点故障，一个从节点将升级为主节点。别的线程就可以拿到相同的锁，这样锁的安全性就没有了。然后redis的作者antirez才提出了一种先进的分布式锁算法，即redlock。

- END -

公粽号：堆栈future

使很多处于迷茫阶段的coder能从这里找到光明，堆栈创世，功在当代，利在千秋