SETNX命令简介
SETNX key value
将 key 的值设为 value，当且仅当 key 不存在。
若给定的 key 已经存在，则 SETNX 不做任何动作。
返回整数，具体为
- 1，当 key 的值被设置
- 0，当 key 的值没被设置
多个进程执行以下Redis命令：
SETNX lock.lock <current time + timeout +1 > //其中1是cover锁获取时间
如果 SETNX 返回1，说明该进程获得锁，SETNX将键 lock.lock 的值设置为锁的超时时间（当前时间 + 锁的有效时间）。
如果 SETNX 返回0，说明其他进程已经获得了锁，进程不能进入临界区。进程可以在一个循环中不断地尝试 SETNX 操作，以获得锁。
1. 如果进程获得锁后，断开了与 Redis 的连接（可能是进程挂掉，或者网络中断），如果没有有效的释放锁的机制，那么其他进程都会处于一直等待的状态，即出现“死锁”。
2. 在使用 SETNX 获得锁时，我们将键 lock.lock 的值设置为锁的有效时间，进程获得锁后，其他进程还会不断的检测锁是否已超时，如果超时，那么等待的进程也将有机会获得锁。当前进程需要在超时时退出，否则超时后，其他进程有可能拿到锁导致多个进程同时拿到锁。
3. 锁超时时，我们不能简单地使用 DEL 命令删除键 lock.lock 以释放锁。考虑以下情况，进程P1已经首先获得了锁 lock.lock，然后进程P1挂掉了。进程P2，P3正在不断地检测锁是否已释放或者已超时，执行流程如下：
P2和P3进程读取键 lock.lock 的值，检测锁是否已超时（通过比较当前时间和键 lock.lock 的值来判断是否超时），P2和P3进程发现锁 lock.lock 已超时，P2执行 DEL lock.lock命令，P2执行 SETNX lock.lock命令，并返回1，即P2获得锁。P3执行 DEL lock.lock命令将P2刚刚设置的键 lock.lock 删除（这步是由于P3刚才已检测到锁已超时）。P3执行 SETNX lock.lock命令，并返回1，即P3获得锁。P2和P3同时获得了锁。
从上面的情况可以得知，在检测到锁超时后，进程不能直接简单地执行 DEL 删除键的操作以获得锁。
为了解决上述算法可能出现的多个进程同时获得锁的问题，我们再来看以下的算法。
我们同样假设进程P1已经首先获得了锁 lock.lock，然后进程P1挂掉了。接下来的情况：
进程P4执行 SETNX lock.lock 以尝试获取锁
由于进程P1已获得了锁，所以P4执行 SETNX lock.lock 返回0，即获取锁失败
P4执行 GET lock.lock 来检测锁是否已超时，如果没超时，则等待一段时间，再次检测
如果P4检测到锁已超时，即当前的时间大于键 lock.lock 的值，P4会执行以下操作
GETSET lock.lock
由于 GETSET 操作在设置键的值的同时，还会返回键的旧值，通过比较键 lock.lock 的旧值是否小于当前时间，可以判断进程是否已获得锁
假如另一个进程P5也检测到锁已超时，并在P4之前执行了 GETSET 操作，那么P4的 GETSET 操作返回的是一个大于当前时间的时间戳，这样P4就不会获得锁而继续等待。
//实例代码
LOCK_TIMEOUT =3
lock =0
lock_timeout =0
lock_key ='lock.lock'# 获取锁
while lock !=1:
now =int(time.time())
lock_timeout = now + LOCK_TIMEOUT +1
lock = redis_client.setnx(lock_key, lock_timeout)
if lock ==1 or (now >int(redis_client.get(lock_key))) and now > int(redis_client.getset(lock_key, lock_timeout)): //解决当锁超时时，两个进程同时判断锁可以获取，只能其中一个可以设置成功
break
else:time.sleep(0.001)
# 已获得锁
do_job()
# 释放锁
now =int(time.time())
if now < lock_timeout:
redis_client.delete(lock_key)
有很多已经实现好的基于redis的分布式锁的封装，详细见 https://redis.io/topics/distlock
