Redis有一系列的命令，特點是以NX結尾，NX是Not eXists的縮寫，如SETNX命令就應該理解為：SET if Not eXists。這系列的命令非常有用，這里講使用SETNX來實現(xiàn)分布式鎖。

用SETNX實現(xiàn)分布式鎖

利用SETNX非常簡單地實現(xiàn)分布式鎖。例如：某客戶端要獲得一個名字foo的鎖，客戶端使用下面的命令進行獲取：

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

如返回1，則該客戶端獲得鎖，把lock.foo的鍵值設置為時間值表示該鍵已被鎖定，該客戶端最后可以通過DEL lock.foo來釋放該鎖。
如返回0，表明該鎖已被其他客戶端取得，這時我們可以先返回或進行重試等對方完成或等待鎖超時。
解決死鎖

上面的鎖定邏輯有一個問題：如果一個持有鎖的客戶端失敗或崩潰了不能釋放鎖，該怎么解決？我們可以通過鎖的鍵對應的時間戳來判斷這種情況是否發(fā)生了，如果當前的時間已經(jīng)大于lock.foo的值，說明該鎖已失效，可以被重新使用。

發(fā)生這種情況時，可不能簡單的通過DEL來刪除鎖，然后再SETNX一次，當多個客戶端檢測到鎖超時后都會嘗試去釋放它，這里就可能出現(xiàn)一個競態(tài)條件,讓我們模擬一下這個場景：

C0操作超時了，但它還持有著鎖，C1和C2讀取lock.foo檢查時間戳，先后發(fā)現(xiàn)超時了。
C1 發(fā)送DEL lock.foo
C1 發(fā)送SETNX lock.foo 并且成功了。
C2 發(fā)送DEL lock.foo
C2 發(fā)送SETNX lock.foo 并且成功了。
這樣一來，C1，C2都拿到了鎖！問題大了！

幸好這種問題是可以避免D，讓我們來看看C3這個客戶端是怎樣做的：

C3發(fā)送SETNX lock.foo 想要獲得鎖，由于C0還持有鎖，所以Redis返回給C3一個0
C3發(fā)送GET lock.foo 以檢查鎖是否超時了，如果沒超時，則等待或重試。
反之，如果已超時，C3通過下面的操作來嘗試獲得鎖：
GETSET lock.foo <current Unix time + lock timeout + 1>
通過GETSET，C3拿到的時間戳如果仍然是超時的，那就說明，C3如愿以償拿到鎖了。
如果在C3之前，有個叫C4的客戶端比C3快一步執(zhí)行了上面的操作，那么C3拿到的時間戳是個未超時的值，這時，C3沒有如期獲得鎖，需要再次等待或重試。留意一下，盡管C3沒拿到鎖，但它改寫了C4設置的鎖的超時值，不過這一點非常微小的誤差帶來的影響可以忽略不計。
注意：為了讓分布式鎖的算法更穩(wěn)鍵些，持有鎖的客戶端在解鎖之前應該再檢查一次自己的鎖是否已經(jīng)超時，再去做DEL操作，因為可能客戶端因為某個耗時的操作而掛起，操作完的時候鎖因為超時已經(jīng)被別人獲得，這時就不必解鎖了。