分布式锁

先假设一个场景：
服务A和服务B，他们都会共享资源C，客户端请求服务A和服务B的时候，都会修改共享资源C，如果修改共享资源C，不具有原子性，就有可能导致覆盖，因此就需要有一个同步锁，即分布式锁。

实现分布式锁，目前比较好的解决方案是利用分布式一致性的基础设施（比如zookeeper, etcd）解决问题，如果是处理简单场景的分布式锁就可以利用Redis来实现，本文主要就是描述如何利用Redis实现分布式锁。

Redis中可以利用SETNX指令实现分布式锁。例如：某客户端要获得一个名字foo的锁，客户端使用下面的命令进行获取：

SETNX lock.foo current Unix time + lock timeout

如返回1，则该客户端获得锁，把lock.foo的键值设置为时间值表示该键已被锁定，该客户端最后可以通过DEL lock.foo来释放该锁。
如返回0，表明该锁已被其他客户端取得，这时我们可以先返回或进行重试等对方完成或等待锁超时。

但事事并没有那么完美，有时候会出现一些极端场景，比如以下情况：
持有锁的客户端失败或崩溃了不能释放锁，我们可以通过锁的键对应的时间戳来判断这种情况是否发生了，如果当前的时间已经大于lock.foo的值，说明该锁已失效，可以被重新使用。问题又来了，如果同时有多个客户端检测到锁超时后都会尝试去释放它，这里就可能出现一个竞争条件，比如：
C0操作超时了，但它还持有着锁，C1和C2读取lock.foo检查时间戳，先后发现超时了。
C1 发送DEL lock.foo
C1 发送SETNX lock.foo 并且成功了。
C2 发送DEL lock.foo
C2 发送SETNX lock.foo 并且成功了。
这样一来，C1，C2都拿到了锁！
那怎么避免呢？
C3发送SETNX lock.foo 想要获得锁，由于C0还持有锁，所以Redis返回给C3一个0
C3发送GET lock.foo 以检查锁是否超时了，如果没超时，则等待或重试。
反之，如果已超时或者不存在，C3通过下面的操作来尝试获得锁：
GETSET lock.foo current Unix time + lock timeout
通过GETSET，C3拿到的时间戳如果仍然是超时的或者不存在，那就说明，C3如愿以偿拿到锁了。
如果在C3之前，有个叫C4的客户端比C3快一步执行了上面的操作，那么C3拿到的时间戳是个未超时的值，这时，C3没有如期获得锁，需要再次等待或重试。尽管C3没拿到锁，但它改写了C4设置的锁的超时值，不过相差不大，可以忽略。另外，持有锁的客户端在解锁之前应该再检查一次自己的锁是否已经超时，再去做DEL操作，因为可能客户端因为某个耗时的操作而挂起，操作完的时候锁因为超时已经被别人获得，这时就不必解锁了。

以下给出用Python实现的代码：

_DEFAULT_TIMEOUT = 1000 #msdef lock(key, timeout=_DEFAULT_TIMEOUT):    while True:        now_time = int(time.time() * 1000)        timestamp = now_time + timeout        result = redis_lock.setnx(key, timestamp)        if result:            print('%s lock success' % key)            return timestamp        out_time = redis_lock.get(key)        if not out_time or now_time > int(out_time):            tmp_time = redis_lock.getset(key, timestamp)            if not tmp_time or now_time > int(tmp_time):                print('%s lock success' % key)                return timestamp        time.sleep(0.01)def unlock(key, lock_timestamp):    now_time = int(time.time() * 1000)    if now_time <= lock_timestamp:        redis_lock.delete(key)    else:        print('%s lock time out' % key)