TOC

Redis 分布式锁

分布式锁

核心需求:一个端点上锁成功之后,在它解锁之前其他端点无法上锁

但是生产环境中,我们需要考虑复杂一点的场景,比如:上锁之后,如果这个端点 hang 了,killed 了,网络不可达了...无法解锁了,怎么办?
PS: 保障锁机制的高性能和高可用又是另一个话题了。

我们需要支持超时解锁。

这样一来,除了服务异常的情况,服务正常运行时,也可能出现锁超时的情况。不管怎么设计这个超时时间,从理论上来讲,有多个端点同时上锁的可能性。程序设计时需要记住这一点。
PS: 在服务正常运行时,自动给锁续期,可以大幅降低这种情况出现的可能性。

万一多个端点同时上锁,那么有一个新的问题必须考虑清楚:如何避免解了别人的锁

要求这个锁必须可以记录状态。解锁时发现不是自己的锁,就打个 WARN 日志跳过。

综合一下,写个伪代码:

endpointFlag = '...' # 随机串或者别的唯一标识
while 1:
    status = lock(endpointFlag)
    if status:
        log('get lock, do_something')
        do_something()
        log('release lock')
        unlock(endpointFlag)
        break
    else:
        log('wait lock')
        sleep(0.1)

Redis 分布式锁的方案

一些比较老的资料采用 SETNX lockKey timestamp 或者 SETNX + EXPIRE 实现上锁(前者需要保障各端点时间完全同步,并且需要不停 GET 检测,就不予考虑了)。
PS: 我看到过一些非常新的文章还在介绍这种方案,非常不应该。
PS: 老方案中,解决这个原子性问题的办法是采用 Lua 脚本来实现(Redis 保证 Lua 的原子性),甚至有一些库(Redisson)设计了非常精妙的处理逻辑,其思想还是非常可以借鉴。

Redis 替我们解决了这个上锁的原子性问题,2.6.12 对 SET 做了拓展,可以设置过期时间。
所以,现在上锁和设置过期时间可以通过 SET 一步完成。

# SET key value 
#     [EX seconds|PX milliseconds|EXAT timestamp|PXAT milliseconds-timestamp|KEEPTTL] 
#     [NX|XX]
#     [GET]

function lock (endpointFlag)) {
    return SET lockKey endpointFlag EX 10 NX
}

function unlock (endpointFlag) {
    lockedBy = GET lockKey
    if lockedBy != endpointFlag:
        log("locked by $lockedBy, ignore")
        return
    DEL lockKey
}