加锁:
SETNX ${lockName} ${value} # set if not exist
如果不存在则插入成功,返回 1,加锁成功;否则返回 0,加锁失败
解锁:
DEL ${lockName}
2 个线程 A、B,线程 A 拿到了锁后,宕机了怎么办?谁来释放锁?
解决:使用自动过期机制:
加锁:
SET ${lockName} ${value} EX 10 NX # atomic opreation
解锁:
DEL ${lockName}
t0 时刻实例1获取到锁,t3 时刻被自动释放(国企),同时实例2获取到锁,t4 时刻实例1再次释放(实例2的锁),实例3又获取到了锁,造成了数据混乱
解决:设置 value 为当前实例线程 id,在解锁时做判断
加锁:
SET ${localName} ${threadId} EX 10 NX
解锁(使用 lua 脚本实现原子性):
current_value = get ${lockName}
if ${threadId} == current_value then
DEL ${lockName}
锁被自动释放的问题仍然存在
启动一个异步线程(WatchDog),获取到锁成功后启动异步线程,每隔 x 秒对当前锁续期 y 秒,直到锁被释放停止
至此,单机版的 Redis 分布式锁就得到了成功实现
主节点加锁成功后崩溃,从节点上位后没有锁的信息
加锁:
解锁:
删除所有实例上的锁
网络延迟超过了锁的过期时间
加锁:
一、获取当前时间
二、按顺序依次向N个Redis实例执行加锁操作
这里的加锁操作和在单实例上执行的加锁操作一样,使用SET命令,带上NX、EX/PX选项,以及带上客户端的唯一标识。当然,如果某个Redis实例发生故障了,为了保证在这种情况下,Redlock算法能够继续运行,我们需要给加锁操作设置一个超时时间。如果客户端在和一个Redis实例请求加锁时,一直到超时都没有成功,那么此时,客户端会和下一个Redis实例继续请求加锁。加锁操作的超时时间需要远远地小于锁的有效时间,一般也就是设置为几十毫秒
三、一旦客户端完成了和所有Redis实例的加锁操作,客户端就要计算整个加锁过程的总耗时
客户端只有在满足两个条件时,才能认为是加锁成功:
在满足了这两个条件后,我们需要重新计算这把锁的有效时间,计算的结果是锁的最初有效时间减去客户端为获取锁的总耗时。如果锁的有效时间已经来不及完成共享数据的操作了,我们可以释放锁,以免出现还没完成共享资源操作,锁就过期了的情况。
当然,如果客户端在和所有实例执行完加锁操作后,没能同时满足这两个条件,那么,客户端就要向所有Redis节点发起释放锁的操作