面试题：分布式锁，谈谈设计思路和方案

面试官：项目有用到分布式锁吗？谈谈设计思路和方案

答：主要根据具体的业务场景展开描述（这边各个项目不一样，就不展开说了），主要是引入redis实现的分布式锁，应该保证互斥性（在任何时候只有一个客户端持有锁，使用setnx），不能死锁（设置过期时间），保证上锁和解锁是同一个客户端（设置不同的value值），业务时间太长，导致锁过期（设置看门狗，自动续锁），锁的重入性（使用redis的hset）。

如果在一个分布式系统中，我们从数据库中读取一个数据，然后修改保存，这种情况很容易遇到并发问题。因为读取和更新保存不是一个原子操作，在并发时就会导致数据的不正确。如果是单机应用，直接使用本地锁就可以避免。如果是分布式应用，应用部署在多个JVM中，没有办法控制，所以引入分布式锁来解决。

互斥性

127.0.0.1:6379> setnx lock value1 #在键lock不存在的情况下，将键key的值设置为value1
(integer) 1
127.0.0.1:6379> setnx lock value2 #试图覆盖lock的值，返回0表示失败
(integer) 0
127.0.0.1:6379> get lock #获取lock的值，验证没有被覆盖
"value1"
127.0.0.1:6379> del lock #删除lock的值，删除成功
(integer) 1
127.0.0.1:6379> setnx lock value2 #再使用setnx命令设置，返回0表示成功
(integer) 1
127.0.0.1:6379> get lock #获取lock的值，验证设置成功

加锁：使用setnx key value命令，如果key不存在，设置value(加锁成功)。如果已经存在lock(也就是有客户端持有锁了)，则设置失败(加锁失败)。

解锁：使用del命令，通过删除键值释放锁。

不能死锁

设置过期时间，到点数据删除，避免导致如果一个客户端持有锁的期间突然崩溃了，就会导致无法解锁，则其他人将无法拿到该锁，锁会一直存在，最终导致出现死锁的现象。

锁过期

有效时间设置多长，假如我的业务操作比有效时间长，我的业务代码还没执行完就自动给我解锁了，不就完蛋了吗。

这个问题就有点棘手了，在网上也有很多讨论，第一种解决方法就是靠程序员自己去把握，预估一下业务代码需要执行的时间，然后设置有效期时间比执行时间长一些，保证不会因为自动解锁影响到客户端业务代码的执行。但是这并不是万全之策，比如网络抖动这种情况是无法预测的，也有可能导致业务代码执行的时间变长，所以并不安全。有一种方法比较靠谱一点，

就是给锁续期。在Redisson框架实现分布式锁的思路，就使用watchDog机制实现锁的续期。当加锁成功后，同时开启守护线程，默认有效期是30秒，每隔10秒就会给锁续期到30秒，只要持有锁的客户端没有宕机，就能保证一直持有锁，直到业务代码执行完毕由客户端自己解锁，如果宕机了自然就在有效期失效后自动解锁。

保证上锁和解锁都是同一个客户端

key的值可以根据业务设置，比如是用户中心使用的，可以命令为USER_REDIS_LOCK，value可以使用uuid保证唯一，用于标识加锁的客户端，保证加锁和解锁都是同一个客户端。

每次解锁可以先判断锁的value是不是当前用户，如果是，说明可以解锁，如果不是，则不能解锁，会导致误解了其他人的锁。

锁的重入性

可重入锁意思是在外层使用锁之后，内层仍然可以使用，那么可重入锁的实现思路又是怎么样的呢？在Redisson实现可重入锁的思路，使用Redis的哈希表存储可重入次数，当加锁成功后，使用hset命令，value(重入次数)则是1。

解锁时，先判断可重复次数是否大于0，大于0则减一，否则删除键值，释放锁资源。