SETNX key value
将 key
的值设为 value
,当且仅当 key
不存在。
若给定的 key
已经存在,则 SETNX 不做任何动作。
SETNX 是『SET if Not eXists』(如果不存在,则 SET)的简写。
1
。0
。redis> EXISTS job # job 不存在
(integer) 0
redis> SETNX job "programmer" # job 设置成功
(integer) 1
redis> SETNX job "code-farmer" # 尝试覆盖 job ,失败
(integer) 0
redis> GET job # 没有被覆盖
"programmer"
Warning
已经证实这个加锁算法带有竞争条件,在特定情况下会造成错误,请不要使用这个加锁算法,具体请参考 http://huangz.iteye.com/blog/1381538 。
SETNX 可以用作加锁原语(locking primitive)。比如说,要对关键字(key) foo
加锁,客户端可以尝试以下方式:
SETNX lock.foo <current Unix time + lock timeout + 1>
如果 SETNX 返回 1
,说明客户端已经获得了锁, key
设置的unix时间则指定了锁失效的时间。之后客户端可以通过 DEL lock.foo
来释放锁。
如果 SETNX 返回 0
,说明 key
已经被其他客户端上锁了。如果锁是非阻塞(non blocking lock)的,我们可以选择返回调用,或者进入一个重试循环,直到成功获得锁或重试超时(timeout)。
处理死锁(deadlock)
上面的锁算法有一个问题:如果因为客户端失败、崩溃或其他原因导致没有办法释放锁的话,怎么办?
这种状况可以通过检测发现——因为上锁的 key
保存的是 unix 时间戳,假如 key
值的时间戳小于当前的时间戳,表示锁已经不再有效。
但是,当有多个客户端同时检测一个锁是否过期并尝试释放它的时候,我们不能简单粗暴地删除死锁的 key
,再用 SETNX 上锁,因为这时竞争条件(race condition)已经形成了:
lock.foo
并检查时间戳, SETNX 都返回 0
,因为它已经被 C3 锁上了,但 C3 在上锁之后就崩溃(crashed)了。lock.foo
发送 DEL 命令。lock.foo
发送 SETNX 并成功。lock.foo
发送 DEL 命令。lock.foo
发送 SETNX 并成功。幸好,以下算法可以避免以上问题。来看看我们聪明的 C4 客户端怎么办:
lock.foo
发送 SETNX 命令。lock.foo
,所以 Redis 向 C4 返回 0
。lock.foo
发送 GET 命令,查看 lock.foo
的锁是否过期。如果不,则休眠(sleep)一段时间,并在之后重试。lock.foo
内的 unix 时间戳比当前时间戳老,C4 执行以下命令:GETSET lock.foo <current Unix timestamp + lock timeout + 1>
lock.foo
之前储存的旧值仍是那个过期时间戳,如果是的话,那么 C4 获得锁。key
进行了修改,这对未来也没什么影响。