[Redis]浅析Redis 分布式锁解决方案

（主要是续约Redisson）

1.锁的设计？

注意互斥性与临界区。

超时释放，避免死锁。

可重入性。一个线程在持有锁的情况可以对其再次请求加锁，防止锁在线程执行完临界区操作之前释放。

2. Redis为什么可以做分布式锁？

利用 Redis 的 SETNX 命令，此命令同样是原子性操作，只有在 key 不存在的情况下，才能 set 成功。而基于 Redis 多机实现的分布式锁Redlock，是Redis 的作者 antirez 为了规范 Redis 分布式锁的实现，提出的一个更安全有效的实现机制。

SET LOCK_ID VALUE NX EX 10 //加锁

DEL LOCK_ID

NX表示值不存在才能SET成功，保证了一个获取锁。

EX 过期时间

3.锁被别人误删了怎么办？

DEL 释放锁之前对锁进行判断，验证当前锁的持有者是否是自己。

加锁时将 value 设置为一个唯一的随机数（或者线程 ID ），释放锁时先判断随机数是否一致，然后再执行释放操作，确保不会错误地释放其它线程持有的锁

使用LUA脚本。

4.锁提前释放了怎么办？

线程 A 在临界区的逻辑还没有执行完，那么这时候线程 B 就可以提前重新获取这把锁，导致临界区代码不能严格的串行执行。

这个在单节点无法解决

可以利用锁的可重入特性，让获得锁的线程开启一个定时器的守护线程，每 expireTime/3 执行一次，去检查该线程的锁是否存在，如果存在则对锁的过期时间重新设置为 expireTime，即利用守护线程对锁进行“续命”，防止锁由于过期提前释放。

当然业务要实现这个守护进程的逻辑还是比较复杂的，可能还会出现一些未知的问题。

使用开源框架 Redisson 。

5.RedLock

为什么出现这种，因为单机实现的分布式锁有一个问题，

就是加锁的时候如果M挂了，那么主从复制是异步的，这样有可能会让线程获取到锁，失去锁的安全性。

获取锁的过程，客户端应执行如下操作：

• 获取当前 Unix 时间，以毫秒为单位。

• 按顺序依次尝试从5个实例使用相同的 key 和具有唯一性的 value（例如 UUID）获取锁。当向 Redis 请求获取锁时，客户端应该设置一个网络连接和响应超时时间，这个超时时间应该小于锁的失效时间。例如锁自动失效时间为10秒，则超时时间应该在5-50毫秒之间。这样可以避免服务器端 Redis 已经挂掉的情况下，客户端还在一直等待响应结果。如果服务器端没有在规定时间内响应，客户端应该尽快尝试去另外一个 Redis 实例请求获取锁。

• 客户端使用当前时间减去开始获取锁时间（步骤1记录的时间）就得到获取锁使用的时间。当且仅当从大多数（N/2+1，这里是3个节点）的 Redis 节点都取到锁，并且使用的时间小于锁失效时间时，锁才算获取成功。

• 如果取到了锁，key 的真正有效时间等于有效时间减去获取锁所使用的时间（步骤3计算的结果）。

• 如果因为某些原因，获取锁失败（没有在至少N/2+1个 Redis 实例取到锁或者取锁时间已经超过了有效时间），客户端应该在所有的 Redis 实例上进行解锁（使用 Redis Lua 脚本）。

释放锁的过程相对比较简单：客户端向所有 Redis 节点发起释放锁的操作，包括加锁失败的节点，也需要执行释放锁的操作，antirez 在算法描述中特别强调这一点，这是为什么呢？

原因是可能存在某个节点加锁成功后返回客户端的响应包丢失了，这种情况在异步通信模型中是有可能发生的：客户端向服务器通信是正常的，但反方向却是有问题的。虽然对客户端而言，由于响应超时导致加锁失败，但是对 Redis节点而言，SET 指令执行成功，意味着加锁成功。因此，释放锁的时候，客户端也应该对当时获取锁失败的那些 Redis 节点同样发起请求。

除此之外，为了避免 Redis 节点发生崩溃重启后造成锁丢失，从而影响锁的安全性，antirez 还提出了延时重启的概念，即一个节点崩溃后不要立即重启，而是等待一段时间后再进行重启，这段时间应该大于锁的有效时间。

关于 Redlock 的更深层次的学习，感兴趣的朋友可以查阅下官方文档：

https://redis.io/topics/distlock

RedLock代价很大，虽然更安全，但是因为需要更多的Redis节点，一般来说在实际业务场景中，使用单点的Redis就可以实现分布式锁的需求。

偶尔出现数据不一致的情况，可通过人工介入回补数据进行解决，正所谓“技术不够，人工来凑”！

转自：

去哪儿技术--Redis分布式锁浅析