一、redis分布式锁的简易实现
用redis实现分布式锁是一个老生常谈的问题了。因为redis单条命令执行的原子性和高性能,当多个客户端执行setnx(相同key)时,最多只有一个获得成功。因此在对可用性要求不是特别高的场景下,redis分布式锁方案不失为一个性价比高的实现。
- 多个客户端执行
setnx lockid random px lock-duration
其中lockid与被锁住资源唯一对应。random为随机值,用于客户端判定自身是否为该锁的owner。lock-duration为锁保持时长,由业务操作耗时决定。 - 对于客户端来说,执行命令后,如果redis返回1,则表示抢到锁;否则没抢到
- 对于抢到锁的客户端,完成业务操作之后,需主动删除该锁。
二、redis分布式锁的注意事项
1. 锁必须要设定一个过期时间
如果不设置过期时间,考虑如下时序:
- 客户端A抢锁成功
- 客户端A的进程异常退出,没来得及主动释放锁
- 其他客户端试图抢锁(毫无疑问是失败的)
如上所示,客户端A抢到锁了,但是由于某些异常导致进程还没有来得及释放锁就退出了。这样其他客户端setnx的返回永远是0,即永远也抢不到锁。
相反,如果设置过期时间,即使客户端A没有主动释放锁,到了过期时间之后redis也会自动释放。
- 客户端A抢锁成功
- 客户端A的进程异常退出,没来得及主动释放锁
- 其他客户端抢锁失败
- 锁自动过期
- 其他客户端抢锁成功
2. 获取锁的命令不能分为两步执行
如果实现为,
setnx lockid
expire lockid lock-duration
除非使用lua script, 否则redis无法支持上述两个命令的原子性,当第一个命令执行完成后,抢到锁的客户端A异常退出了,那么其他客户端将永远抢到锁。
注:redis在2.6.12版本后已经支持setnx命令的TTL参数,这个问题不复存在
3. 锁的值必须设置为随机值
假设锁的值为固定值,考虑如下情况
- 客户端A抢到锁,执行业务操作
- 客户端A由于某些原因阻塞,超过了锁有效时间,导致锁自动被释放
- 客户端B抢锁成功,执行操作
- 客户端A从阻塞中恢复,主动释放锁,执行
del lockid
- 客户端B创建的锁被客户端A删除。此时客户端C抢锁成功,客户端B与C的业务操作产生竞态。
如果锁的值是随机值,并且每次成功加锁时,都记录该随机值的话,并且释放锁时,判断锁的值是否等于记录值,等于则del, 不等于则跳过。
4. 释放锁时,需使用lua script封装保证原子性
如果不使用lua封装释放锁的逻辑,考虑时序:
- 客户端A抢到锁,执行业务操作
- 客户端A完成业务操作,主动释放锁:首先
get lockid
,发现记录值和锁当前值相等,判定该锁为自己所加。 - 客户端A由于某些原因阻塞(比如GC),超过锁有效时间,锁被redis自动释放
- 客户端B成功抢锁
- 客户端A从阻塞中恢复,执行下一步
del lockid
,客户端B加的锁被A释放 - 客户端C抢锁成功,B与C产生竞态
而redis执行lua script的原子性能避免上述问题。
5. 多个redis节点保证高可用
如果只在一个redis节点上抢锁,如果该节点宕机,将导致所有的客户端都抢不到锁,无法保证服务的高可用。
三、redsync实现一览
redlock是一种基于redis的分布式锁算法。而redsync是redlock算法的golang实现,其暴露了三个API:加锁(Lock),解锁(Unlock),续锁(Extend)
1. Lock
- 首先随机生成一个value
- 针对所有redis连接,执行
set lockid value NX PX lock-duration
- 如果超过半数连接上的请求都正常返回,且now < start + (1 - factor) * expire,意味着抢锁成功
- 否则先清理key, 然后重试,重试时间间隔可由用户自定义。
2. Unlock
针对所有redis实例,执行lua脚本。这里会判断key对应的value和Mutex在Lock时使用的value值是否一致,只有一致了执行del命令。此举是为了保证每个客户端不会释放别的客户端创建的锁。
if redis.call("GET", KEYS[1]) == ARGV[1] then
return redis.call("DEL", KEYS[1])
else
return 0
end
如果有超过半数实例上的请求返回,则意味着释放锁成功。否则判定失败。
3. Extend
Extend操作是为了保证当客户端业务处理时长超过expire时间时,客户端可主动延长锁的过期时间,而无需二次抢锁。针对所有redis连接,执行lua脚本,重新设置过期时间
if redis.call("GET", KEYS[1]) == ARGV[1] then
return redis.call("pexpire", KEYS[1], ARGV[2])
else
return 0
end
半数以上返回成功,则意味着Extend成功