分布式锁之Redis实现

太过爱你忘了你带给我的痛 2022-11-21 15:19 116阅读 0赞

**目录**

分布式锁应具备的特性

使用 setnx 实现分布式锁

使用 setnx 和 expire 实现

使用 set 扩展命令实现

通过lua脚本来执行释放锁操作

集群环境下分布式锁存在的问题

Redlock

--------------------

## 分布式锁应具备的特性 ##

互斥性：互斥是锁的基本特征，同一时刻只能有一个线程持有锁，执行临界操作；

超时释放：超时释放是锁的另一个必备特性，通过超时释放，防止不必要的线程等待和资源浪费；

可重入性：在分布式环境下，同一个节点上的同一个线程如果获取了锁之后，再次请求还是可以成功；

高性能和高可用：加锁和解锁的开销要尽可能的小，同时也需要保证高可用，防止分布式锁失效；

支持阻塞和非阻塞性：对比 Java 语言中的 wait() 和 notify() 等操作，这个一般是在业务代码中实现，比如在获取锁时通过 while(true) 或者轮询来实现阻塞操作。

--------------------

## 使用 setnx 实现分布式锁 ##

Redis 支持 setnx 指令，只在 key 不存在的情况下，将 key 的值设置为 value，若 key 已经存在，则 setnx 命令不做任何动作。

使用 setnx 实现分布式锁的方案，获取锁的方法很简单，指定一个key值，如果 setnx 返回 1，则说明该进程获得锁；如果 setnx 返回 0，则说明其他进程已经获得了锁，进程不能进入临界区；如果需要阻塞当前进程，可以在一个循环中不断尝试 setnx 操作。

释放锁时只要删除对应的 key 就可以，为了防止系统业务进程出现异常导致锁无法释放，使用 Java 中的 try-catch-finally 来完成锁的释放。

对比一下上面说的分布式锁特性，使用这种方式实现分布式锁的问题很明显：不支持超时释放锁，如果进程在加锁后宕机，则会导致锁无法删除，其他进程无法获得锁。

--------------------

## 使用 setnx 和 expire 实现 ##

在使用 setnx 获取锁之后，通过 expire 给锁加一个过期时间，利用 Redis 的缓存失效策略，进行锁的超时清除。但是在 Redis 中，setnx 和 expire 这两条命令不具备原子性。如果一个线程在执行完 setnx 之后突然崩溃，导致锁没有设置过期时间，那么这个锁就会一直存在，无法被其他线程获取。

--------------------

## 使用 set 扩展命令实现 ##

从 Redis 2.6.12 版本开始， `SET` 命令的行为可以通过一系列参数来修改：

*  `EX seconds：`将键的过期时间设置为 `seconds` 秒。 执行 `SET key value EX seconds` 的效果等同于执行 `SETEX key seconds value` 。
 *  `PX milliseconds：`将键的过期时间设置为 `milliseconds` 毫秒。 执行 `SET key value PX milliseconds` 的效果等同于执行 `PSETEX key milliseconds value` 。
 *  `NX`：只在键不存在时， 才对键进行设置操作。 执行 `SET key value NX` 的效果等同于执行 `SETNX key value` 。
 *  `XX：`只在键已经存在时， 才对键进行设置操作。

因此我们可以直接通过 set 命令与 NX 参数来代替setnx + expire，并且具备原子性：

> SET key value expireTime NX

执行逻辑：

if(set(key,expireTime,value) ==1){
         try{
            //业务处理
         }finally{
           //释放锁
           del(key)
         }
    }

--------------------

## 通过lua脚本来执行释放锁操作 ##

在上面的逻辑中，虽然解决了 key 与 expireTime的原子性问题，但如果应用到具体的业务场景中，依然可能出现一些问题：

1.  客户端 A 获取锁的时候设置了 key 的过期时间为 2 秒，客户端 A 在获取到锁之后，业务逻辑方法执行了 3 秒；
2.  客户端 A 获取的锁被 Redis 过期机制自动释放，客户端 B 请求锁成功，出现并发执行；
3.  客户端 A 执行完业务逻辑后，释放锁，删除对应的 key；
4.  客户端 A 释放的锁实际是客户端 B 持有的锁，导致客户端 B 暴露在了无锁状态下。

为了解决这个问题，我们可以在每个线程加锁前，将 value 指定一个唯一值（例如UUID），释放锁将取到的 value 与之前设置的值进行比较，如果相同才会释放锁，从而避免该线程释放其它线程的锁。

我们一般通过lua脚本来完成释放锁的过程：

if redis.call('get', KEYS[1]) == ARGV[1] then 
        return redis.call('del', KEYS[1]) 
    else 
        return 0 
    end

--------------------

## 集群环境下分布式锁存在的问题 ##

集群环境下，Redis 通过主从复制来实现数据同步，Redis 的主从复制（Replication）是异步的，所以单节点下可用的方案在集群的环境中可能会出现问题，在故障转移（Failover） 过程中丧失锁的安全性。

由于 Redis 集群数据同步是异步的，假设 Master 节点获取到锁后在未完成数据同步的情况下，发生节点崩溃，此时在其他节点依然可以获取到锁，出现多个客户端同时获取到锁的情况。

--------------------

## Redlock ##

关于集群下如何实现分布式锁，Redis 的作者提出了 Redlock 算法，Redlock 算法是在单 Redis 节点基础上引入的高可用模式，Redlock 基于 N 个完全独立的 Redis 节点，一般是大于 3 的奇数个（通常情况下 N 可以设置为 5），可以基本保证集群内各个节点不会同时宕机。

假设当前集群有 5 个节点，运行 Redlock 算法的客户端依次执行下面各个步骤：

1.  客户端记录当前系统时间，以毫秒为单位；
2.  依次尝试从 5 个 Redis 实例中，使用相同的 key 获取锁，当向 Redis 请求获取锁时，客户端应该设置一个网络连接和响应超时时间，超时时间应该小于锁的失效时间，避免因为网络故障出现的问题；
3.  客户端使用当前时间减去开始获取锁时间就得到了获取锁使用的时间，当且仅当从半数以上的 Redis 节点获取到锁，并且当使用的时间小于锁失效时间时，锁才算获取成功；
4.  如果获取到了锁，key 的真正有效时间等于有效时间减去获取锁所使用的时间，减少超时的几率；
5.  如果获取锁失败，客户端应该在所有的 Redis 实例上进行解锁，即使是上一步操作请求失败的节点，防止因为服务端响应消息丢失，但是实际数据添加成功导致的不一致。

在 Redis 官方推荐的 Java 客户端 Redisson 中，内置了对 RedLock 的实现。

[https://redis.io/topics/distlock][https_redis.io_topics_distlock]  
[https://github.com/redisson/redisson/wiki][https_github.com_redisson_redisson_wiki]

[https_redis.io_topics_distlock]: https://redis.io/topics/distlock
[https_github.com_redisson_redisson_wiki]: https://github.com/redisson/redisson/wiki