如何用Redis实现分布式锁(2)—— 集群版

Posted by ZY on September 2, 2018

单机版实现的局限性

在上一篇文章中,我们讨论了Redis分布式锁的实现,简单回顾下。

获取锁:

set file:9527 ${random_value} NX EX ${timeout}

释放锁,调用lua脚本:

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

这套实现机制,在只有一个Redis实例的情况下,确实很完美。

然而,大多数生产环境,都不可能只部署一个Redis,至少也是主从架构:

更多的是主从+分片的架构:

当然主从架构也可以进化为一主多从架构乃至主从链架构(Master-Salve Chain):

而其实在主从架构下,之前那套分布式锁的机制,就已经失效了,原因正如之前说的:

如果A往Master放入了一把锁,然后再数据同步到Slave之前,Master crash,Slave被提拔为Master,这时候Master上面就没有锁了,这样其他进程也可以拿到锁,违法了锁的互斥性。

那么,要怎么解决这个问题呢?

Redlock算法

针对Redis集群架构,redis的作者antirez提出了Redlock算法,来实现集群架构下的分布式锁。

Redlock算法并不复杂,我们先简单描述一下,假设我们Redis分片下,有三个Master的节点,这三个Master,又各自有一个Slave:

好,现在客户端想获取一把分布式锁:

  • 记下开始获取锁的时间 startTime
  • 按照A->B->C的顺序,依次向这三台Master发送获取锁的命令。客户端在等待每台Master回响应时,都有超时时间timeout。举个例子,客户端向A发送获取锁的命令,在等了timeout时间之后,都没收到响应,就会认为获取锁失败,继续尝试获取下一把锁
  • 如果获取到超过半数的锁,也就是 3/2+1 = 2把锁,这时候还没完,要记下当前时间endTime
  • 计算拿到这些锁花费的时间 costTime = endTime - startTime,如果costTime小于锁的过期时间expireTime,则认为获取锁成功
  • 如果获取不到超过一半的锁,或者拿到超过一半的锁时,计算出costTime>=expireTime,这两种情况下,都视为获取锁失败
  • 如果获取锁失败,需要向全部Master节点,都发生释放锁的命令,也就是那段Lua脚本

看完这个Redlock算法,相信你会有很多疑问,下面就一起来追问Redlock。

追问Redlock

1、为什么要给每个获取锁的请求设置timeout

为了防止在某个出了问题的Master节点上,浪费太多时间。一旦超时了,马上尝试下一个。

2、获取了过半数的锁之后,还要不要继续获取

这个没有约束。

你可以选择适可而止,这样可以提高获取锁的速度,总共三台,A和B都拿到了,就不必去拿C了。

你也可以很贪心,A和B都拿到了,还要去拿C。这有什么好处呢?后面会跟你说。

3、如果costTime只比expireTime小一点点,会不会有问题?

当然有问题,这样你前脚刚拿到锁,走进门,后脚分布式锁就过期了,别人也拿到锁,进门了,互斥性被打破。

解决办法是,每个请求的timeout要比expireTime小很多,比如你的expireTime是10s,那么timeout可以设置为50ms,这样costTime最多也就50*3=150ms,剩下的9850ms,这九秒多钟,你都可以用来执行代码,保证不会有其他进程可以进入。

For example if the auto-release time is 10 seconds, the timeout could be in the ~ 5-50 milliseconds range. This prevents the client from remaining blocked for a long time trying to talk with a Redis node which is down: if an instance is not available, we should try to talk with the next instance ASAP.

当然,如果你的代码执行了9850ms还没执行完,那别的进程还是可以抢到锁。这也是一个暂时无解的问题。

4、释放锁时,为什么不能只向成功获取到锁的Master发送释放命令,而要向所有的Master节点发送

很简单,假设你向Master A发送了获取锁的命令,set命令执行成功了,但是在回响应时发送了故障,响应没发回来,过了超时时间后,你会认为获取锁失败,而实际上,锁已经在redis那边生效了。

所以在释放锁的时候,必须向全部节点都发生命令,不管你到底有没有在那节点上面获取到锁。

5、如果有节点crash,锁不也还是会丢失吗?

的确,单机时候的问题,在集群依然存在。

Redlock算法,在有节点重启或者crash的情况下,也会有可能无法达到互斥的目的。

假设有三个节点ABC:

  • 进程1在B和C上拿到了锁
  • 这时候B crash了
  • 如果B没有Slave节点,那么B会重启,如果数据还没备份,那么重启后B上的锁就丢了
  • 又或者B有Slave节点,但是crash时,Master B的数据还没同步到Slave,Slave被提拔为Master
  • 不管有没有Slave,其他进程都有可能在Bcrash掉之后,在B上拿到锁,再加上在A拿到的锁,就可以拿到超过半数的锁,这样就有两个进程同时拿到了锁,互斥性被打破

对于上面这个问题,Redis的作者,同时也是Redlock的作者antirez,提出了delay的解决方案,就是让B别那么快重启,稍微等一下,等的时间,就是分布式锁的最大过期时间,等到其他节点上的锁都过期了,你再重启,对外提供服务。

对于有Slave的情况,也可以用类似的方案,Slave先别那么快接替Master,稍微等一下下。

6、会不会有锁饥饿的问题?

还是三台Master节点,现在有三个进程同时要加同一把锁,会不会出现每次都是一个进程抢到一把锁的情况?

这是有可能的。

解决办法1:
获取锁失败后,随机休息一段时间

解决办法2:
如果客户端在发现,就算后面全部的锁,都被我抢到,加起来也不能超过半数,这时候就不再继续往下抢。

举个例子,进程1抢到了节点A的锁,进程2抢到节点B的,这时候进程3想过来抢锁,按照ABC的顺序,逐个抢,A和B都抢不过别人,于是掐指一算,就算C让我抢到了,我也抢不到超过半数了,没必要继续抢了,我还是先尝试抢一下A吧。

这样就不会出现三把锁,分别被三个不同的进程抢的情况了。

Redisson(一个Java的redis客户端)在实现redlock时就采用了这个解决方案。

RedissonMultiLock line248:

现在让我们回过头来看第2个问题,获取了过半数的锁之后,还要不要继续获取?

之前说了,不继续获取可以提高速度,但是贪心点继续获取也并非一无是处,比如你已经获取了A和B,如果把C也获取了,那么就算后面A挂掉了,别人也最多只能从恢复过来的A上获取到锁,还是拿不到超过半数的。

Redlock实现:Redisson

上面讲的只是Redlock的算法,具体怎么用代码来实现,可以看redlock各种语言的客户端源码,比如Java的实现,就可以看看Redisson。

我在看的过程中,就发现redisson在释放锁的时候,只是释放了成功获取到的锁。
RedissonMultiLock line248:

当然,或许redisson有其他考虑,这个还不得而知。

针对这个疑惑,给redisson提了个issuse(https://github.com/redisson/redisson/issues/1606),不过还没有答复 ( ̄▽ ̄)/

参考