《八股文》9道分布式锁面试题

说说分布式锁吧？

对于一个单机的系统，我们可以通过synchronized或者ReentrantLock等这些常规的加锁方式来实现，然而对于一个分布式集群的系统而言，单纯的本地锁已经无法解决问题，所以就需要用到分布式锁了，通常我们都会引入三方组件或者服务来解决这个问题，比如数据库、Redis、Zookeeper等。

通常来说，分布式锁要保证互斥性、不死锁、可重入等特点。

互斥性指的是对于同一个资源，任意时刻，都只有一个客户端能持有锁。

不死锁指的是必须要有锁超时这种机制，保证在出现问题的时候释放锁，不会出现死锁的问题。

可重入指的是对于同一个线程，可以多次重复加锁。

那你分别说说使用数据库、Redis和Zookeeper的实现原理？

数据库的话可以使用乐观锁或者悲观锁的实现方式。

乐观锁通常就是数据库中我们会有一个版本号，更新数据的时候通过版本号来更新，这样的话效率会比较高，悲观锁则是通过for update的方式，但是会带来很多问题，因为他是一个行级锁，高并发的情况下可能会导致死锁、客户端连接超时等问题，一般不推荐使用这种方式。

Redis是通过set命令来实现，在2.6.2版本之前，实现方式可能是这样：

setNX命令代表当key不存在时返回成功，否则返回失败。

但是这种实现方式把加锁和设置过期时间的步骤分成两步，他们并不是原子操作，如果加锁成功之后程序崩溃、服务宕机等异常情况，导致没有设置过期时间，那么就会导致死锁的问题，其他线程永远都无法获取这个锁。

之后的版本中，Redis提供了原生的set命令，相当于两命令合二为一，不存在原子性的问题，当然也可以通过lua脚本来解决。

set命令如下格式：

key 为分布式锁的key

value 为分布式锁的值，一般为不同的客户端设置不同的值

NX 代表如果要设置的key已存在，则取消设置

EX 代表过期时间为秒，PX则为毫秒，比如上面示例中为10秒过期

Zookeeper是通过创建临时顺序节点的方式来实现。

1. 当需要对资源进行加锁时，实际上就是在父节点之下创建一个临时顺序节点。

2. 客户端A来对资源加锁，首先判断当前创建的节点是否为最小节点，如果是，那么加锁成功，后续加锁线程阻塞等待

3. 此时，客户端B也来尝试加锁，由于客户端A已经加锁成功，所以客户端B发现自己的节点并不是最小节点，就会去取到上一个节点，并且对上一节点注册监听

4. 当客户端A操作完成，释放锁的操作就是删除这个节点，这样就可以触发监听事件，客户端B就会得到通知，同样，客户端B判断自己是否为最小节点，如果是，那么则加锁成功

你说改为set命令之后就解决了问题？那么还会不会有其他的问题呢？

虽然set解决了原子性的问题，但是还是会存在两个问题。

锁超时问题

比如客户端A加锁同时设置超时时间是3秒，结果3s之后程序逻辑还没有执行完成，锁已经释放。客户端B此时也来尝试加锁，那么客户端B也会加锁成功。

这样的话，就导致了并发的问题，如果代码幂等性没有处理好，就会导致问题产生。

锁误删除

还是类似的问题，客户端A加锁同时设置超时时间3秒，结果3s之后程序逻辑还没有执行完成，锁已经释放。客户端B此时也来尝试加锁，这时客户端A代码执行完成，执行释放锁，结果释放了客户端B的锁。

那上面两个问题你有什么好的解决方案吗？

锁超时

这个有两个解决方案。

1. 针对锁超时的问题，我们可以根据平时业务执行时间做大致的评估，然后根据评估的时间设置一个较为合理的超时时间，这样能一大部分程度上避免问题。

2. 自动续租，通过其他的线程为将要过期的锁延长持有时间

锁误删除

每个客户端的锁只能自己解锁，一般我们可以在使用set命令的时候生成随机的value，解锁使用lua脚本判断当前锁是否自己持有的，是自己的锁才能释放。

#加锁
SET key random_value NX EX 10
#解锁
if redis.call("get",KEYS[1]) == ARGV[1] then
    return redis.call("del",KEYS[1])
else
    return 0
end

了解RedLock算法吗？

因为在Redis的主从架构下，主从同步是异步的，如果在Master节点加锁成功后，指令还没有同步到Slave节点，此时Master挂掉，Slave被提升为Master，新的Master上并没有锁的数据，其他的客户端仍然可以加锁成功。

对于这种问题，Redis作者提出了RedLock红锁的概念。

RedLock的理念下需要至少2个Master节点，多个Master节点之间完全互相独立，彼此之间不存在主从同步和数据复制。

主要步骤如下：

1. 获取当前Unix时间

2. 按照顺序依次尝试从多个节点锁，如果获取锁的时间小于超时时间，并且超过半数的节点获取成功，那么加锁成功。这样做的目的就是为了避免某些节点已经宕机的情况下，客户端还在一直等待响应结果。举个例子，假设现在有5个节点，过期时间=100ms，第一个节点获取锁花费10ms，第二个节点花费20ms，第三个节点花费30ms，那么最后锁的过期时间就是100-(10+20+30)，这样就是加锁成功，反之如果最后时间