SETNX key value
自1.0.0起可用。
时间复杂度： O(1)
如果不存在，则设置key为保存字符串。在这种情况下，它等于SET。当已经保存一个值时，不执行任何操作。SETNX 是短期的“ SET如果ñ OTË X派”。valuekeykey
返回值
整数回复，具体为：
1 如果密钥已设置
0 如果密钥没有设置
例子
redis> SETNX mykey "Hello" (integer) 1 redis> SETNX mykey "World" (integer) 0 redis> GET mykey "Hello"
设计模式：锁定 SETNX
请注意：
以下模式不利于Redlock算法，该算法实现起来稍微复杂一些，但提供了更好的保证并具有容错能力。
无论如何，我们记录旧的模式，因为某些现有的实现链接到此页面作为参考。此外，Redis 命令如何用于装载编程原语是一个有趣的例子。
无论如何，即使假定一个单实例锁定原语，从2.6.12开始，可以创建一个更简单的锁定原语，与此处讨论的等价，使用
SET 命令获取锁，以及一个简单的 Lua 脚本来释放锁。该模式记录在SET命令页面中。
也就是说，SETNX 可以被用作历史上被用作锁定原语。例如，要获取密钥的锁定foo，客户端可以尝试以下操作：
SETNX lock.foo
如果 SETNX 返回1客户端获得的锁定，则将该lock.foo关键字设置为不再认为该锁定有效的 Unix 时间。客户端稍后将使用DEL lock.foo以释放锁。
如果 SETNX 返回0该键已被某个其他客户端锁定。如果它是非阻塞锁，我们可以返回给调用者，或者输入一个循环重试以保持锁，直到我们成功或某种超时过期。
处理死锁
在上述锁定算法中存在一个问题：如果客户端出现故障，崩溃或无法释放锁，会发生什么情况？可以检测到这种情况，因为锁定键包含 UNIX 时间戳。如果这样的时间戳等于当前的 Unix 时间，则该锁不再有效。
发生这种情况时，我们不能仅仅通过调用 DEL 来移除锁，然后尝试发出 SETNX，因为这里存在争用条件，当多个客户端检测到过期的锁并尝试释放它时。
C1和C2读取lock.foo以检查时间戳，因为它们0在执行SETNX 之后都收到，因为锁仍然由持有锁之后崩溃的 C3 持有。
C1发送 DEL lock.foo
C1发送SETNX lock.foo并成功
C2发送 DEL lock.foo
C2发送SETNX lock.foo并成功
错误：由于竞争条件，C1和C2都获得了锁定。
幸运的是，使用以下算法可以避免此问题。让我们看看我们的理智客户C4如何使用好的算法：
C4发送SETNX lock.foo以获取锁
崩溃的客户端C3仍然拥有它，所以Redis将回复0给C4。
C4发送GET lock.foo来检查锁是否过期。如果不是，它会睡眠一段时间并从一开始就重试。
相反，如果锁由于 Unix 时间lock.foo比当前 Unix 时间早而过期，C4会尝试执行：
GETSET lock.foo
由于 GETSET 语义，C4可以检查存储的旧值key是否仍然是过期的时间戳。如果是这样，那就得到了锁。
如果另一个客户端(例如C5)比C4速度更快并通过 GETSET 操作获取了锁定，则C4 GETSET 操作将返回一个未过期的时间戳。C4将从第一步重新开始。请注意，即使C4在未来几秒钟内将键设置为几秒，这也不是问题。
为了使这种锁定算法更加健壮，持有锁的客户端应该始终检查超时在 DEL 用于解锁密钥之前没有过期，因为客户端失败可能很复杂，不仅会崩溃，而且会阻止大量时间对付某些操作并尝试在很长时间后发出 DEL(当 LOCK 已被另一客户端占用时)。