基于分布式原理解析Redis分布式锁的实现

// redis version < 2.6.12 
SETNX lock_key lock_value
EXPIRE lock_key ttl_with_seconds

// redis version >= 2.6.12 
SET lock_key lock_value NX PX ttl_with_seconds

Redis的SETNX可以保证只有第一次设置可以成功, 那么获取锁的Safety是可以保证的

但是在2.6.12之前SETNX和EXPIRE是两条命令, 这样会存在如下情况:

会导致lock_key无法正确释放, 从而不能满足Liveness

问题有了, 如何解决?

1. Redis2.6.12之前版本可以采用 lua 脚本将命令一次提交, 保证操作原子性
2. 升级到2.6.12之后版本

野狐禅版本, golang示例

func AcquireLock(lock_key string, lock_value string, timeout uint32) bool {
     // SET lock_key lock_value NX PX ttl_with_seconds 
     // return is_success
}

func ReleaseLock(lock_key string) {
     // DELETE lock_key 
}

func Process(lock_key string, lock_value string, timeout uint32) {
    if  AcquireLock(lock_key, lock_value, timeout) {
        // 无论业务逻辑执行是否成功, 一定释放锁
        defer func() {
          ReleaseLock(lock_key)
        }()

        // do something
        // maybe process over lock TTL
    }
}

看上去很完美的实现. But Really Good Job?

惨案是如何发生的

来看个正规军版本

func ReleaseLock(lock_key string, lock_value string) bool {
     // 在释放锁的时候加入乐观锁校验, 并通过lua脚本保证原子性
     // return_val = eval (
     //           if redis.call("get",lock_key) == lock_value then
     //                return redis.call("del",lock_key)
     //           else
     //                return 0
     //           end
     // )
     return return_val!=0
}

func Process(lock_key string, lock_value string, timeout uint32) {
    if  AcquireLock(lock_key, lock_value, timeout) {
        // 无论业务逻辑执行是否成功, 一定释放锁
        defer func() {
            release_success := ReleaseLock(lock_key)
            if !release_success {
                // 如果锁释放失败, 说明锁超时, 其他人已经获取了锁, 需要根据业务决定是否rollback刚刚的操作
                // maybe rollback?? 
            }
        }()

        // do something
        // maybe process over lock TTL
    }
}

最后需要注意的事情

由于使用了lock_value作为释放锁时的乐观校验, 那么lock_value的选择就需要一定的技巧

这里推荐第三种方案, 可参考twitter的snowflake算法

顺便鄙视一下某些无良码农, 仅仅是对snowflake算法的位进行调整, 就人模狗样的跑出来说实现了nb的分布式ID算法>_<