分布式锁

ChenSino大约 10 分钟

1、写在前面

以前一直没搞清楚分布式锁和分布式事务，对其概念以及使用场景很模糊，今天查查资料，好好总结一下分布式事务和分布式锁。另外提前说一句，使用redis来解决分布式、高并发问题存在一些困难，Redis 分布式锁只能作为一种缓解并发的手段，如果要完全解决并发问题，仍需要数据库的防并发手段。

2、锁和分布式锁解决了什么问题？

单机锁：解决单进程中多线程同时操作共有数据（比如java堆数据）带来的安全问题，强调的是单机服务中线程安全问题，这种场景很常见，比如单机多线程售票的例子。这种锁直接通过java的本地锁实现即可，可以使用java自带的synchroized和Lock

分布式锁：解决集群服务中，多个相同服务操作同一个资源数据的安全问题。比如淘宝双十一抢购，为了支持高并发，下订单的服务肯定是集群模式而非单机，比如有一个商品促销，数量共有1000个，下订单的集群服务是10个，如果抢购开始，这10个集群服务应该是共同拥有这1000个商品，应当避免在并发情况下销售的总量超过1000的情况，这种就是典型的分布式锁需要处理的问题。

3、分布式锁特性

互斥性：同一时刻只能有一个服务（进程）持有锁
可重入性：同一服务节点上的同一个线程如果获取了锁之后能够再次获取锁
锁超时：和J.U.C中的锁一样支持锁超时，防止死锁
高性能和高可用：加锁和解锁需要高效，同时也需要保证高可用，防止分布式锁失效
具备阻塞和非阻塞性：能够及时从阻塞状态中被唤醒

4、分布式锁的实现

4.1 redis实现

实现思路：利用redis处理网络请求是单线程（其他模块是多线程），并且其操作具有原子性。

4.1.1 单机redis实现（采用逐步升级的方式来进行分析）

采用redis 的SETNX(SET IF NOT EXIST)，key和value我们可以随意指定，若key不存在此操作成功返回1,如果key已存在则set失败返回0。正常情况第一个抢占锁的服务设置肯定是返回1的，如果此时其他服务（JVM进程）再次来set相同的key就返回0,代表抢锁失败。
```
SETNX lock_source_key lock_value # 加锁
do something #获取锁以后的业务处理代码
DEL lock_source_key #业务处理完以后释放锁
```

如果仅仅是设置key,是存在问题的，比如第一个服务抢到了锁，但是服务挂掉、或者带宽堵塞、GC等种种原因，导致其迟迟不能释放锁，那么其他服务就一直没有机会抢到锁，这样肯定是不合理的。

在1的基础上升级一下，给key加一个过期时间，如果出现意外情况，key到期以后可以自动释放

SETNX lock_source_key lock_value # 加锁
EXPIRE lock_source_key 10 #假设过期时间是10s
do something #获取锁以后的业务处理代码
DEL lock_source_key #业务处理完以后释放锁

经过以上升级后依然会存在问题，细心的读者可能已经发现，因为SETNX 和 EXPIRE是两步分开的操作，所以仍然会存在安全问题，因为redis的原子性指的是一个操作，这两是分开的两个操作，并不是原子的。比如，当服务SETNX成功后，在EXPIRE 这个操作执行前又挂了，那就又回到第1个那样的场景，导致抢到锁，但是却一直不释放锁。

在2的基础上再次升级，为了解决 SETNX 和 EXPIRE 两个操作非原子性的问题，可以使用 Redis 的 SET 指令的扩展参数，使得 SETNX 和 EXPIRE 这两个操作可以原子执行
```
SET lock_source_key lock_value NX EX 10 #加锁
do something
DEL lock_source_key #释放锁
```
- NX 表示只有当 lock_resource_id 对应的 key 值不存在的时候才能 SET 成功。保证了只有第一个请求的客户端才能获得锁，而其它客户端在锁被释放之前都无法获得锁。
- EX 10 表示这个锁 10 秒钟后会自动过期，业务可以根据实际情况设置这个时间的大小。

再次升级后，看似完美，实则不然：
锁被提前释放。假如线程 A 在加锁和释放锁之间的逻辑执行的时间过长（或者线程 A 执行过程中被堵塞），以至于超出了锁的过期时间后进行了释放，但线程 A 在临界区的逻辑还没有执行完，那么这时候线程 B 就可以提前重新获取这把锁，导致临界区代码不能严格的串行执行。
锁被误删。假如以上情形中的线程 A 执行完后，它并不知道此时的锁持有者是线程 B，线程 A 会继续执行 DEL 指令来释放锁，如果线程 B 在临界区的逻辑还没有执行完，线程 A 实际上释放了线程 B 的锁。

为了避免以上情况，建议不要在执行时间过长的场景中使用 Redis 分布式锁，同时一个比较安全的做法是在执行 DEL 释放锁之前对锁进行判断，验证当前锁的持有者是否是自己。

具体实现就是在加锁时将 value 设置为一个唯一的随机数（或者线程 ID ），释放锁时先判断随机数是否一致，然后再执行释放操作，确保不会错误地释放其它线程持有的锁，除非是锁过期了被服务器自动释放，整个过程如下：

# 先产生一个随机数，可以用uuid等
SET lock_source_key random_value NX EX 10 #加锁
do something
if random_value == get(lock_source_key)   #释放锁前，先判断当前服务是否是锁的持有者
DEL lock_source_key #释放锁

但判断 value 和删除 key 是两个独立的操作，并不是原子性的，所以这个地方需要使用 Lua 脚本进行处理，因为 Lua 脚本可以保证连续多个指令的原子性执行。

if redis.call("get",KEYS[1] == ARGV[1]) then  #java代码中调用lua脚本判断
	return redis.call("DEL",KEYS[1])          #如果判断相等则用lua调用del释放锁
else
	return 0;                                 #如果当前服务不是锁拥有者直接返回0,即不释放锁，因为此时锁的所有者不是当前服务

基于 Redis 单节点的分布式锁基本完成了，但是这并不是一个完美的方案，只是相对完全一点，因为它并没有完全解决当前线程执行超时锁被提前释放后，其它线程乘虚而入的问题。要完美解决此问题需要使用 Redisson 的分布式锁，具体实现比较复杂以后补充。

4.1.2 多机redis实现

在4.1.1中，是单机部署，如果用在多机redis部署又会产生新的问题。加锁时只作用在一个 Redis 节点上，即使 Redis 通过 Sentinel 保证了高可用，但由于 Redis 的复制是异步的，Master 节点获取到锁后在未完成数据同步的情况下发生故障转移，此时其他客户端上的线程依然可以获取到锁，因此会丧失锁的安全性。

整个过程如下：

客户端 A 从 Master 节点获取锁。
Master 节点出现故障，主从复制过程中，锁对应的 key 没有同步到 Slave 节点。
Slave 升级为 Master 节点，但此时的 Master 中没有锁数据。
客户端 B 请求新的 Master 节点，并获取到了对应同一个资源的锁。
出现多个客户端同时持有同一个资源的锁，不满足锁的互斥性。

正因为如此，在 Redis 的分布式环境中，Redis 的作者 antirez 提供了 RedLock 的算法来实现一个分布式锁，该算法大概是这样的：

假设有 N（N>=5）个 Redis 节点，这些节点完全互相独立，不存在主从复制或者其他集群协调机制，确保在这 N 个节点上使用与在 Redis 单实例下相同的方法获取和释放锁。

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

获取当前 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 还提出了延时重启的概念，即一个节点崩溃后不要立即重启，而是等待一段时间后再进行重启，这段时间应该大于锁的有效时间。

分布式锁

1、写在前面

2、锁和分布式锁解决了什么问题？

3、分布式锁特性

4、分布式锁的实现

4.1 redis实现

4.1.1 单机redis实现（采用逐步升级的方式来进行分析）

4.1.2 多机redis实现

4.2 zookeeper实现

4.3 基于数据库实现

4.4 MemCached 实现

5、参考博客