分布式锁问题
我看在技术大群里面有人问分布式锁问题，说是被面试官各种刁难，我是实在看不下去了，面试官意思很明确，你们有造火箭的经验吗，有的话来他们公司造自行车，没有的话：今天面试就到这里了！
但是说实话面试官没必要因为这个问题继续追问，没啥意思，但是又不得不问，确实有些企业用到分布式锁了。
没办法，逼迫你必须得背会它。
接下来就说下群友面试碰到的问题，因为候选人可能自己已经掌握了实现分布式锁的原理，但是被面试官问到细节可能就不清楚了，因此给大家讲下这块。
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 -
