使用Redis的 SETNX 命令可以實(shí)現(xiàn)分布式鎖，下文介紹其實(shí)現(xiàn)方法。

SETNX命令簡介

命令格式

SETNX key value

將 key 的值設(shè)為 value，當(dāng)且僅當(dāng) key 不存在。

若給定的 key 已經(jīng)存在，則 SETNX 不做任何動(dòng)作。

SETNX 是SET if Not eXists的簡寫。

返回值

返回整數(shù)，具體為

- 1，當(dāng) key 的值被設(shè)置

- 0，當(dāng) key 的值沒被設(shè)置

例子

redis> SETNX mykey “hello” 
(integer) 1 
redis> SETNX mykey “hello” 
(integer) 0 
redis> GET mykey 
“hello” 
redis>

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

多個(gè)進(jìn)程執(zhí)行以下Redis命令：

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

如果 SETNX 返回1，說明該進(jìn)程獲得鎖，SETNX將鍵 lock.foo 的值設(shè)置為鎖的超時(shí)時(shí)間（當(dāng)前時(shí)間 + 鎖的有效時(shí)間）。

如果 SETNX 返回0，說明其他進(jìn)程已經(jīng)獲得了鎖，進(jìn)程不能進(jìn)入臨界區(qū)。進(jìn)程可以在一個(gè)循環(huán)中不斷地嘗試 SETNX 操作，以獲得鎖。

解決死鎖

考慮一種情況，如果進(jìn)程獲得鎖后，斷開了與 Redis 的連接（可能是進(jìn)程掛掉，或者網(wǎng)絡(luò)中斷），如果沒有有效的釋放鎖的機(jī)制，那么其他進(jìn)程都會(huì)處于一直等待的狀態(tài)，即出現(xiàn)“死鎖”。

上面在使用 SETNX 獲得鎖時(shí)，我們將鍵 lock.foo 的值設(shè)置為鎖的有效時(shí)間，進(jìn)程獲得鎖后，其他進(jìn)程還會(huì)不斷的檢測鎖是否已超時(shí)，如果超時(shí)，那么等待的進(jìn)程也將有機(jī)會(huì)獲得鎖。

然而，鎖超時(shí)時(shí)，我們不能簡單地使用 DEL 命令刪除鍵 lock.foo 以釋放鎖。考慮以下情況，進(jìn)程P1已經(jīng)首先獲得了鎖 lock.foo，然后進(jìn)程P1掛掉了。進(jìn)程P2，P3正在不斷地檢測鎖是否已釋放或者已超時(shí)，執(zhí)行流程如下：

• P2和P3進(jìn)程讀取鍵 lock.foo 的值，檢測鎖是否已超時(shí)（通過比較當(dāng)前時(shí)間和鍵 lock.foo 的值來判斷是否超時(shí)）
• P2和P3進(jìn)程發(fā)現(xiàn)鎖 lock.foo 已超時(shí)
• P2執(zhí)行 DEL lock.foo命令
• P2執(zhí)行 SETNX lock.foo命令，并返回1，即P2獲得鎖
• P3執(zhí)行 DEL lock.foo命令將P2剛剛設(shè)置的鍵 lock.foo 刪除（這步是由于P3剛才已檢測到鎖已超時(shí)）
• P3執(zhí)行 SETNX lock.foo命令，并返回1，即P3獲得鎖
• P2和P3同時(shí)獲得了鎖

從上面的情況可以得知，在檢測到鎖超時(shí)后，進(jìn)程不能直接簡單地執(zhí)行 DEL 刪除鍵的操作以獲得鎖。

為了解決上述算法可能出現(xiàn)的多個(gè)進(jìn)程同時(shí)獲得鎖的問題，我們再來看以下的算法。

我們同樣假設(shè)進(jìn)程P1已經(jīng)首先獲得了鎖 lock.foo，然后進(jìn)程P1掛掉了。接下來的情況：

1、進(jìn)程P4執(zhí)行 SETNX lock.foo 以嘗試獲取鎖

2、由于進(jìn)程P1已獲得了鎖，所以P4執(zhí)行 SETNX lock.foo 返回0，即獲取鎖失敗

3、P4執(zhí)行 GET lock.foo 來檢測鎖是否已超時(shí)，如果沒超時(shí)，則等待一段時(shí)間，再次檢測

4、如果P4檢測到鎖已超時(shí)，即當(dāng)前的時(shí)間大于鍵 lock.foo 的值，P4會(huì)執(zhí)行以下操作

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

5、由于 GETSET 操作在設(shè)置鍵的值的同時(shí)，還會(huì)返回鍵的舊值，通過比較鍵 lock.foo 的舊值是否小于當(dāng)前時(shí)間，可以判斷進(jìn)程是否已獲得鎖

6、假如另一個(gè)進(jìn)程P5也檢測到鎖已超時(shí)，并在P4之前執(zhí)行了 GETSET 操作，那么P4的 GETSET 操作返回的是一個(gè)大于當(dāng)前時(shí)間的時(shí)間戳，這樣P4就不會(huì)獲得鎖而繼續(xù)等待。注意到，即使P4接下來將鍵 lock.foo 的值設(shè)置了比P5設(shè)置的更大的值也沒影響。

另外，值得注意的是，在進(jìn)程釋放鎖，即執(zhí)行 DEL lock.foo 操作前，需要先判斷鎖是否已超時(shí)。如果鎖已超時(shí)，那么鎖可能已由其他進(jìn)程獲得，這時(shí)直接執(zhí)行 DEL lock.foo 操作會(huì)導(dǎo)致把其他進(jìn)程已獲得的鎖釋放掉。

程序代碼

用以下Python代碼來實(shí)現(xiàn)上述的使用 SETNX 命令作分布式鎖的算法。

LOCK_TIMEOUT = 3
lock = 0
lock_timeout = 0
lock_key = 'lock.foo'

# 獲取鎖
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)

以上就是本文的全部內(nèi)容，希望對(duì)大家的學(xué)習(xí)有所幫助，也希望大家多多支持腳本之家。