起始版本：1.0.0

時間復雜度：O(1)

將key設置值為value，如果key不存在，這種情況下等同SET命令。 當key存在時，什么也不做。SETNX是”SET if Not eXists”的簡寫。

返回值
Integer reply, 特定值:

1 如果key被設置了
0 如果key沒有被設置
例子

redis> SETNX mykey "Hello" (integer) 1 redis> SETNX mykey "World" (integer) 0 redis> GET mykey "Hello" redis>

Design pattern: Locking with !SETNX
設計模式：使用!SETNX加鎖
Please note that:

請注意：

不鼓勵以下模式來實現the Redlock algorithm ，該算法實現起來有一些復雜，但是提供了更好的保證并且具有容錯性。

無論如何，我們保留舊的模式，因為肯定存在一些已實現的方法鏈接到該頁面作為引用。而且，這是一個有趣的例子說明Redis命令能夠被用來作為編程原語的。

無論如何，即使假設一個單例的加鎖原語，但是從 2.6.12 開始，可以創建一個更加簡單的加鎖原語，相當于使用SET命令來獲取鎖，并且用一個簡單的 Lua 腳本來釋放鎖。該模式被記錄在SET命令的頁面中。

也就是說，SETNX能夠被使用并且以前也在被使用去作為一個加鎖原語。例如，獲取鍵為foo的鎖，客戶端可以嘗試一下操作：

SETNX lock.foo <current Unix time + lock timeout + 1>

如果客戶端獲得鎖，SETNX返回1，那么將lock.foo鍵的Unix時間設置為不在被認為有效的時間。客戶端隨后會使用DEL lock.foo去釋放該鎖。

如果SETNX返回0，那么該鍵已經被其他的客戶端鎖定。如果這是一個非阻塞的鎖，才能立刻返回給調用者，或者嘗試重新獲取該鎖，直到成功或者過期超時。

處理死鎖
以上加鎖算法存在一個問題：如果客戶端出現故障，崩潰或者其他情況無法釋放該鎖會發生什么情況？這是能夠檢測到這種情況，因為該鎖包含一個Unix時間戳，如果這樣一個時間戳等于當前的Unix時間，該鎖將不再有效。

當以下這種情況發生時，我們不能調用DEL來刪除該鎖，并且嘗試執行一個SETNX，因為這里存在一個競態條件，當多個客戶端察覺到一個過期的鎖并且都嘗試去釋放它。

C1 和 C2 讀lock.foo檢查時間戳，因為他們執行完SETNX后都被返回了0，因為鎖仍然被 C3 所持有，并且 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檢查該鎖是否已經過期。如果沒有過期，C4 客戶端將會睡眠一會，并且從一開始進行重試操作
另一種情況，如果因為 lock.foo鍵的Unix時間小于當前的Unix時間而導致該鎖已經過期，C4 會嘗試執行以下的操作：

GETSET lock.foo <current Unix timestamp + lock timeout + 1>

由于GETSET 的語意，C4會檢查已經過期的舊值是否仍然存儲在lock.foo中。如果是的話，C4 會獲得鎖
如果另一個客戶端，假如為 C5 ，比 C4 更快的通過GETSET操作獲取到鎖，那么 C4 執行GETSET操作會被返回一個不過期的時間戳。C4 將會從第一個步驟重新開始。請注意：即使 C4 在將來幾秒設置該鍵，這也不是問題。
為了使這種加鎖算法更加的健壯，持有鎖的客戶端應該總是要檢查是否超時，保證使用DEL釋放鎖之前不會過期，因為客戶端故障的情況可能是復雜的，不止是崩潰，還會阻塞一段時間，阻止一些操作的執行，并且在阻塞恢復后嘗試執行DEL（此時，該LOCK已經被其他客戶端所持有）

原文出處

總結

以上是生活随笔為你收集整理的Redis命令：SETNX key value（SET if Not eXists）的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。