浅谈用Redis实现分布式锁的方案及细节

r囧r小猫 2023-09-26 17:14 48阅读 0赞

### 前言 ###

我们都知道，在面对并发问题时，有**加锁操作**和**保证原子操作**两种解决方案。当我们采用加锁操作的时候，因为Redis多采用集群的方式部署，因此我们就需要考虑到锁在分布式系统中使用的注意事项。接下来就看看Redis的分布式锁问题。

### 单机锁 ###

说到分布式锁，首先我们得了解【单机锁】。单机锁比较简单，不用考虑分布式系统中各个服务的资源、网络等差异。

单机锁使用起来也很简单，用一个变量就能实现锁必备的互斥功能。比如设置一个锁变量lock，当lock=0时，说明锁空闲着；当lock=1时，说明此时锁被某个线程占用了。在进行互斥操作时先获取lock的值，只有lock=0才能继续，当操作完成后，再将锁释放出来。

### 对分布式锁的要求 ###

既然单机锁这么简单，为什么分布式锁就很复杂呢？

上面将单机锁的时候也有提到，分布式锁用于分布式系统中，系统中每台服务器的资源、网络状况都不同，我们需要在不同的服务器存储锁变量。锁的操作（加锁、释放锁）在不同的情况下，就会衍生出相应的问题。

我们对分布式锁的要求很简单，总结就是：

*  **锁操作（加锁、释放锁），需要保证锁操作的原子性。**
 *  **分布式系统，要考虑到系统故障的场景。当某些服务器实例发生故障时，要保证分布式锁能正常使用。**

![format_png][]

如图，多个进程同时请求对mysql某个数据操作，首先要去获取分布式锁。图例中只有进程1获取到锁，因此加锁后进行下一步的操作；而其他2个进程因为没有获取到锁不能往下操作，这样就做到了互斥。

分布式锁，实现的方式有很多，也就是需要在一个系统中维护锁变量lock。而基于性能的考量，选择Redis作为分布式锁的场景很常见。

### Redis单个节点分布式锁的实现 ###

**要实现分布式锁，首要的就是保证操作的互斥性**。在Redis中有`SETNX`命令，这个命令的含义是：若key不存在，才去设置它的值；key存在的话就不操作。

这样一来，分布式系统的多个客户端可通过该命令达到互斥的要求。

![format_png 1][]

如上面图例：

1.  客户端a在要更新mysql资源时，先向Redis分布式锁申请加锁，也就是执行`SETNX lock 1`,加锁成功。
2.  客户端b也申请加锁，但被客户端a已经加锁了，因此加锁失败，不往下执行。
3.  客户端a加锁成功后，更新MySQL操作。操作完成后，再删除lock变量`DEL lock`。

整个过程就是这样，但是我们再仔细想想就会发现这种方式有个很大的漏洞。**那就是当客户端a加锁成功后，如果在操作mysql的过程中发生异常了，锁就不会释放。这样也就死锁了，其他的客户端都别想拿到锁了。**

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

这个死锁的问题，你可能会说解决起来也不麻烦，给锁加个过期时间不就行了。于是乎，操作命令变成了这样：

127.0.0.1:6379> SETNX lock 1
    (integer) 1
    127.0.0.1:6379> EXPIRE lock 5
    (integer) 1
    复制代码

经过`EXPIRE`操作后，就不用担心锁不释放的问题了。

但我们仔细想想，这里加锁和给锁设置过期时间是分为2步走的，也就是说不是原子性操作，如果执行完上锁操作后，如果还没来得及给锁设置过期时间客户端就异常了，这样也会造成死锁。

因此，将这2条命令原子化才是关键。庆幸的是，`SET`命令支持将这2步一次性执行了（Redis版本要>=2.6.12）。命令示例：

127.0.0.1:6379> SET lock 1 EX 5 NX
    OK
    复制代码

这样一来，死锁的问题解决了。但你认为这样就万事大吉了吗？显然不是，有一个场景还需要考虑到，那就是：锁过期时间到了被自动释放后，等客户端正常操作完成后，又会去释放锁。具体来说如下：

1.  客户端a申请锁lock成功，然后更新MySQL去了；
2.  因为mysql连接问题，客户端a更新操作，超过了设定的过期时间，于是lock被自动释放了；
3.  客户端b这时申请lock成功，也开始更新MySQL了；
4.  MySQL连接正常了，客户端a更新MySQL完成，然后释放锁lock。（此时lock正在被客户端b用着呢）。

**这种场景下，锁过期了被释放会被其他的客户端加锁成功，然后客户端a成功更新MySQL后又会去释放客户端b的锁。**

总结来说这种场景存在2个问题：

*  **设置的过期时间不合理**：我还没操作完你就让锁过期了。导致这种情况的原因有很多，单单增加锁的过期时间并不能完全解决问题。因为网络状况、代码操作逻辑异常都影响到过期时间。
 *  **释放了别的进程锁**：最后一步客户端a释放了别的客户端的锁，这种情况是不应该发生的。解决方法如下。

#### 如何避免释放了别的进程锁 ####

解决方法简单，在获取到锁时，写入唯一标识就可以了。比如说线程ID。

127.0.0.1:6379> set lock {thread_id} ex 5 nx
    OK
    复制代码

当要释放锁的时候，先判断一下锁的唯一标识，这样就可以避免释放别的进程锁。

redis_client.del('lock') if redis_client.get('lock') == {thread_id}
    复制代码

但上述命令是分2步走的（查询+删除），为了保证原子性，我们可以用**Lua脚本**来执行上述命令。脚本可以这样写：

if redis.call("GET", KEYS[1]) == ARGV[1]
    then
    	return redis.call("DEL", KEYS[1])
    else
    	return 0
    end
    复制代码

调用脚本命令就是：`redis-cli --eval lua.script lock, {thread_id}`。

备注：Redis使用lua脚本的语法是：

redis-cli --eval {lua_path} KEYS[1] KEYS[2]... , ARGV[1] ARGV[2]...
    
    --eval：  		执行lua脚本的命令
    {lua_path}： 		lua脚本的路径
    KEYS[1] KEYS[2]：       lua脚本中要操作的redis键，我们可以在lua脚本中用KEYS[1]，KEYS[2]，KEYS[3]指定多个
    ARGV[1] ARGV[2]：	传入到lua脚本的参数，在脚本中用ARGV[1]，ARGV[2]...来获取。
    复制代码

这样一来，Redis分布式锁的实现，除了上述过期时间不好把握外，基本能满足要求。

**我们使用Redis做分布式锁的步骤可总结为：**

1.  **获取锁：** `SET lock {唯一标识} EX {过期时间} NX`
2.  **更新操作：比如说更新mysql资源。**
3.  **释放锁资源：用lua脚本判断锁是不是自己加的，是的话再释放锁（** `DEL lock` **）**

#### 锁过期时间怎么设定才好 ####

锁的过期时间，如果设置的不合理，自动过期的可能性就会大大增加。

在解决这个问题上，Java中有个SDK叫做**Redisson。** 它在使用分布式锁时，加锁的同时有开启一个**看门狗线程。这个线程会定时去检查锁的过期时间，若锁快过期了，而更新操作还没完成，看门狗会延长锁的过期时间，也就是重新设置过期时间。**

如果不使用Java语言，我们也可借鉴Redisson的做法，在加锁的同时开启一个守护线程。

Redis单个节点的分布式锁实现就说到这，接下来看看Redis多个节点该图和实现分布式锁。

### Redis多个节点的分布式锁（**Redlock方案**） ###

Redis的使用，往往不是单机用，用主从集群的模式部署最多。而在该模式下，分布式锁的使用会带来新的问题。比如下面场景：

1.  客户端a在主库上执行加锁命令（SET）成功。
2.  主库发生故障，而步骤1的SET命令还没来得及同步到从库上。
3.  主从切换后，原从库被推举为主库，锁就在节点上丢失了。

![format_png 2][]

为解决这个问题，Redis提供了**Redlock方案。要使用Redlock方案，要有2个前提：**

*  **只部署主库，不部署从库及哨兵。**
 *  **主库部署多个，官方推荐>=5个。**

**Redlock的使用流程大致如下：**

1.  客户端获取到当前的时间戳。
2.  客户端按顺序向部署的N个Redis实例执行加锁操作。在设定时间内，不管加锁成功还是失败，都会继续向下一个实例申请加锁操作。
3.  若加锁成功的实例个数>= (N/2) + 1，并且加锁的总耗时要<锁设定的过期时间，**Redlock**就判断加锁成功，反之就是加锁失败。
4.  加锁成功了，就继续往下操作，比如操作MySQL资源；若加锁失败，则会向所有节点发起锁释放的操作请求。

**由上面流程可见，Redlock的设计规则就是：**

*  **客户端要在所有实例上申请加锁，只有保证大多数节点加锁成功了才判定为加锁成功。**
 *  **加锁的总耗时要 < 锁设定的过期时间。**
 *  **释放锁的时候，要向所有节点发起锁释放的请求，不管之前加锁是否成功。**

**Redlock的应用，可以提升Redis分布式锁的可靠性。但是，Redlock并非没有缺陷和漏洞。**

业界的分布式系统专家**Martin**就曾质疑过Redlock的设计方案，主要是提到了Redlock的效率和正确性。效率不用多说，给全部节点发起加锁的规则就会影响效率。

正确性方面，因为分布式系统中，**时钟偏移**的情况无法避免，运维成本很高。

**总的来说，Redlock设计繁杂，还得部署多个节点，运维难度大。我们在实现Redis分布式锁的时候，用主从+哨兵的集群方案就基本够用了。**

### 小结 ###

本文讲了Redis是如何实现分布式锁的，单个Redis节点和多节点的实现和问题是不一样的。

在使用的时候，如果追求效率，单节点的分布式锁就够用了，缺点就是过期时间不好把握，因为网络情况不好预估；如果要保证正确性，Redlock也是可以考虑的，但运维方面的问题需要提前考虑好。

[format_png]: https://img-blog.csdnimg.cn/img_convert/09c7e05f6a9b272dbf9ff9f7ce7762cc.webp?x-oss-process=image/format,png
[format_png 1]: https://img-blog.csdnimg.cn/img_convert/d4a68ab0ecb1de4ffa08fc3b9bfd4ef4.webp?x-oss-process=image/format,png
[format_png 2]: https://img-blog.csdnimg.cn/img_convert/16f956190211239d9d17d0f9570bd457.webp?x-oss-process=image/format,png