目录

单机上的锁和分布式锁的联系与区别

分布式锁的两个要求

基于单个 Redis 节点实现分布式锁

上锁

解锁

上锁、判断、解锁如何保证原子性？

setnx

风险点1 ：未释放锁

解决： 锁变量设置一个过期时间

风险点2 ：B释放了A得锁

解决：设置锁得值要能区分来自不同客户端或不同线程的锁操作

lua脚本释放锁

执行lua脚本

基于多个 Redis 节点实现高可靠的分布式锁

分布式锁算法 Redlock

总结

单机上的锁和分布式锁的联系与区别

单机上得锁： 一个线程调用加锁操作，其实就是检查锁变量值是否为 0。如果是 0，就把锁的变量值设置为 1，表示获取到锁，如果不是 0，就返回错误信息，表示加锁失败，已经有别的线程获取到锁了。而一个线程调用释放锁操作，其实就是将锁变量的值置为 0，以便其它线程可以来获取锁。

换个锁得值可以自定义，然后判断之

分布式锁：分布式锁同样可以用一个变量来实现。客户端加锁和释放锁的操作逻辑，也和单机上的加锁和释放锁操作逻辑一致：加锁时同样需要判断锁变量的值，根据锁变量值来判断能否加锁成功；释放锁时需要把锁变量值设置为 0，表明客户端不再持有锁。

此外，分布式锁变量需要由一个共享存储系统来维护。

使用分布式锁得三部曲：

1. 读取
2. 判断
3. 设置共享存储系统中的锁变量值

分布式锁的两个要求

• 实现分布式锁时， 我们需要保证这些锁操作的原子性；
• 共享存储系统保存了锁变量，如果共享存储系统发生故障或宕机，那么客户端也就无法进行锁操作了。在实现分布式锁时，我们需要考虑保证共享存储系统的可靠 性，进而保证锁的可靠性(例如zk)

基于单个 Redis 节点实现分布式锁

Redis 可以使用键值对来保存锁变量，再接收和处理不同客户端发送的加锁和释放锁的操作请求。

上锁

?

客户端 A 和 C 同时请求加锁。因为 Redis 处理客户端命令都是单线程处理请求，所以，即使客户端 A 和 C 同时把加锁请求发给了 Redis，Redis 也会串行处理它们的请求。

单线程为什么那么快呢？

解锁

?

当客户端A 持有锁时，锁变量 lock_key 的值为 1。客户端 A 执行释放锁操作后，Redis 将

lock_key 的值置为 0，表明已经没有客户端持有锁了。

上锁、判断、解锁如何保证原子性？

setnx

其实目前通常所说的setnx命令，并非单指redis的setnx key value这条命令。

一般代指redis中对set命令加上nx参数进行使用， set这个命令，目前已经支持这么多参数可选：

SET key value [EX seconds|PX milliseconds] [NX|XX] [KEEPTTL]

具体用法参考 https://redis.io/commands/set

可以用 SETNX 和 DEL 命令组合来实现加锁和释放锁操作

// 加锁
SETNX lock_key 1
// 业务逻辑
DO THINGS
// 释放锁
DEL lock_key

风险点1 ：未释放锁

执行了 SETNX 命令、加锁之后，紧接着却在操作共享数据时发生了异常，结果一直没有执行最后的 DEL 命令释放锁

解决： 锁变量设置一个过期时间

风险点2 ：B释放了A得锁

客户端 A 执行了 SETNX 命令加锁后，假设客户端 B 执行了DEL 命令释放锁，此时，客户端 A 的锁就被误释放了。如果客户端 C 正好也在申请加锁， 就可以成功获得锁，进而开始操作共享数据

解决：设置锁得值要能区分来自不同客户端或不同线程的锁操作

fileloader解析文件就是这么使用分布式锁得

lua脚本释放锁

Lua 脚本（unlock.script）实现的释放锁操作的伪代码，其中，KEYS[1]表示lock_key，ARGV[1]是当前客户端的唯一标识，这两个值都是我们在执行 Lua 脚本时作为参数传入的。

//释放锁 比较unique_value是否相等，避免误释放
if redis.call("get",KEYS[1]) == ARGV[1] then
    return redis.call("del",KEYS[1])
else
    return 0
end

执行lua脚本

redis-cli --eval unlock.script lock_key , unique_value

释放锁操作的逻辑也包含了读取锁变量、判断值、删除锁变量的多个操作，而 Redis 在执行 Lua 脚本时， 可以以原子性的方式执行，从而保证了锁释放操作的原子性。

基于多个 Redis 节点实现高可靠的分布式锁

Redis 实例发生故障宕机，锁变量就没有了。此时，客户端也无法进行锁操作了，这就会影响到业务的正常执行

分布式锁算法 Redlock

Redis 的开发者 Antirez 提出了分布式锁算法 Redlock。

Redlock 算法的基本思路，是让客户端和多个独立的 Redis 实例依次请求加锁，如果客户端能够和半数以上的实例成功地完成加锁操作，那么我们就认为，客户端成功地获得分布 式锁了，否则加锁失败。这样一来，即使有单个 Redis 实例发生故障，因为锁变量在其它实例上也有保存，所以，客户端仍然可以正常地进行锁操作，锁变量并不会丢失。

第一步是，客户端获取当前时间。

第二步是，客户端按顺序依次向 N 个 Redis 实例执行加锁操作。

这里的加锁操作和在单实例上执行的加锁操作一样，使用 SET 命令，带上 NX，EX/PX 选项，以及带上客户端的唯一标识。当然，如果某个 Redis 实例发生故障了，为了保证在这种情况下，Redlock 算法能够继续运行，我们需要给加锁操作设置一个超时时间。

如果客户端在和一个 Redis 实例请求加锁时，一直到超时都没有成功，那么此时，客户端会和下一个 Redis 实例继续请求加锁。加锁操作的超时时间需要远远地小于锁的有效时间，一般也就是设置为几十毫秒。

第三步是，一旦客户端完成了和所有 Redis 实例的加锁操作，客户端就要计算整个加锁过程的总耗时。

客户端只有在满足下面的这两个条件时，才能认为是加锁成功。

1. 条件一：客户端从超过半数（大于等于 N/2+1）的 Redis 实例上成功获取到了锁；
2. 条件二：客户端获取锁的总耗时没有超过锁的有效时间。

第四步：在满足了这两个条件后，我们需要重新计算这把锁的有效时间，计算的结果是锁的最初有效时间减去客户端为获取锁的总耗时。

Redlock的争议 http://zhangtielei.com/posts/blog-redlock-reasoning.html

总结

K大评论

1、使用 SET $lock_key $unique_val EX $second NX 命令保证加锁原子性，并为锁设置过期时间

2、锁的过期时间要提前评估好，要大于操作共享资源的时间

3、每个线程加锁时设置随机值，释放锁时判断是否和加锁设置的值一致，防止自己的锁被别人释放

4、释放锁时使用 Lua 脚本，保证操作的原子性(实际业务中只是设置了过期时间自动释放锁)

5、基于多个节点的 Redlock，加锁时超过半数节点操作成功，并且获取锁的耗时没有超过锁的有效时间才算加锁成功( 感觉思想有点类似于zk )

6、Redlock 释放锁时，要对所有节点释放（即使某个节点加锁失败了），因为加锁时可能发生服务端加锁成功，由于网络问题，给客户端回复网络包失败的情况，所以需要把所有节点可能存的锁都释放掉

7、使用 Redlock 时要避免机器时钟发生跳跃，需要运维来保证，对运维有一定要求，否则可能会导致 Redlock 失效。例如共 3 个节点，线程 A 操作 2 个节点加锁成功，但其中 1 个节点机器时钟发生跳跃，锁提前过期，线程 B 正好在另外 2 个节点也加锁成功，此时 Redlock 相当于失效了（Redis 作者和分布式系统专家争论的重要点就在这）

8、如果为了效率，使用基于单个 Redis 节点的分布式锁即可，此方案缺点是允许锁偶尔失效，优点是简单效率高

9、如果是为了正确性，业务对于结果要求非常严格，建议使用 Redlock，但缺点是使用比较重，部署成本高

?