likes
comments
collection

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

作者站长头像
站长
· 阅读数 20

本文正在参加「金石计划 . 瓜分6万现金大奖」

前言

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

单机锁

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

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

对分布式锁的要求

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

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

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

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

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

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

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

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

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

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

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

如上面图例:

  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. 主从切换后,原从库被推举为主库,锁就在节点上丢失了。

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

为解决这个问题,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也是可以考虑的,但运维方面的问题需要提前考虑好。