更多精彩内容,请关注微信公众号:后端技术小屋

一、redis分布式锁的简易实现

用redis实现分布式锁是一个老生常谈的问题了。因为redis单条命令执行的原子性和高性能,当多个客户端执行setnx(相同key)时,最多只有一个获得成功。因此在对可用性要求不是特别高的场景下,redis分布式锁方案不失为一个性价比高的实现。

  1. 多个客户端执行setnx lockid random px lock-duration
    其中lockid与被锁住资源唯一对应。random为随机值,用于客户端判定自身是否为该锁的owner。lock-duration为锁保持时长,由业务操作耗时决定。
  2. 对于客户端来说,执行命令后,如果redis返回1,则表示抢到锁;否则没抢到
  3. 对于抢到锁的客户端,完成业务操作之后,需主动删除该锁。

二、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成功

推荐阅读

更多精彩内容,请扫码关注微信公众号:后端技术小屋。如果觉得文章对你有帮助的话,请多多分享、转发、在看。
二维码