使用 Redis的SETNX命令實現分布式鎖

2022-03-06 06:12:37 字數 1879 閱讀 9483

使用redis的 setnx 命令可以實現分布式鎖,下文介紹其實現方法。

setnx key value

將 key 的值設為 value,當且僅當 key 不存在。 

若給定的 key 已經存在,則 setnx 不做任何動作。 

setnx 是set if not exists的簡寫。

返回整數,具體為 

- 1,當 key 的值被設定 

- 0,當 key 的值沒被設定

redis> setnx mykey 「hello」 

(integer) 1

redis> setnx mykey 「hello」

(integer) 0

redis> get mykey

「hello」

redis>

多個程序執行以下redis命令:

setnx lock.foo

如果 setnx 返回1,說明該程序獲得鎖,setnx將鍵 lock.foo 的值設定為鎖的超時時間(當前時間 + 鎖的有效時間)。 

如果 setnx 返回0,說明其他程序已經獲得了鎖,程序不能進入臨界區。程序可以在乙個迴圈中不斷地嘗試 setnx 操作,以獲得鎖。

考慮一種情況,如果程序獲得鎖後,斷開了與 redis 的連線(可能是程序掛掉,或者網路中斷),如果沒有有效的釋放鎖的機制,那麼其他程序都會處於一直等待的狀態,即出現「死鎖」。

上面在使用 setnx 獲得鎖時,我們將鍵 lock.foo 的值設定為鎖的有效時間,程序獲得鎖後,其他程序還會不斷的檢測鎖是否已超時,如果超時,那麼等待的程序也將有機會獲得鎖。

然而,鎖超時時,我們不能簡單地使用 del 命令刪除鍵 lock.foo 以釋放鎖。考慮以下情況,程序p1已經首先獲得了鎖 lock.foo,然後程序p1掛掉了。程序p2,p3正在不斷地檢測鎖是否已釋放或者已超時,執行流程如下:

從上面的情況可以得知,在檢測到鎖超時後,程序不能直接簡單地執行 del 刪除鍵的操作以獲得鎖。

為了解決上述演算法可能出現的多個程序同時獲得鎖的問題,我們再來看以下的演算法。 

我們同樣假設程序p1已經首先獲得了鎖 lock.foo,然後程序p1掛掉了。接下來的情況:

另外,值得注意的是,在程序釋放鎖,即執行 del lock.foo 操作前,需要先判斷鎖是否已超時。如果鎖已超時,那麼鎖可能已由其他程序獲得,這時直接執行 del lock.foo 操作會導致把其他程序已獲得的鎖釋放掉。

用以下python**來實現上述的使用 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)

Redis中setnx的使用

setnx是 set if not exists 的縮寫,只有不存在的時候才設定,可以利用它來實現鎖的效果。setnx key value 若給定的 key 已經存在,則 setnx 不做任何動作。set命令可用選項的基本語法 set key value ex seconds px millisec...

正確地使用Redis的SETNX實現鎖機制

setnx,是set if not exists 的縮寫,也就是只有不存在的時候才設定,設定成功時返回 1 設定失敗時返回 0 可以利用它來實現鎖的效果,但是很多人在使用的過程中都有一些問題沒有考慮到。例如某個查詢資料庫的介面因為請求量比較大所以加了快取,並設定快取過期後重新整理。當併發量比較大並且...

正確地使用Redis的SETNX實現鎖機制

setnx,是set if not exists 的縮寫,也就是只有不存在的時候才設定,設定成功時返回 1 設定失敗時返回 0 可以利用它來實現鎖的效果,但是很多人在使用的過程中都有一些問題沒有考慮到。例如某個查詢資料庫的介面因為請求量比較大所以加了快取,並設定快取過期後重新整理。當併發量比較大並且...