高併發下的redis加鎖的幾種實現方式

2021-10-16 22:32:06 字數 2355 閱讀 5975

redis加鎖分類

redis能用的的加鎖命令分表是incr、setnx、set

第一種鎖命令incr

這種加鎖的思路是, key 不存在,那麼 key 的值會先被初始化為 0 ,然後再執行 incr 操作進行加一。

然後其它使用者在執行 incr 操作進行加一時,如果返回的數大於 1 ,說明這個鎖正在被使用當中。

1、 客戶端a請求伺服器獲取key的值為1表示獲取了鎖

2、 客戶端b也去請求伺服器獲取key的值為2表示獲取鎖失敗

3、 客戶端a執行**完成,刪除鎖

4、 客戶端b在等待一段時間後在去請求的時候獲取key的值為1表示獲取鎖成功

5、 客戶端b執行**完成,刪除鎖

$redis->incr($key);

$redis->expire($key, $ttl); //設定生成時間為1秒

第二種鎖setnx

這種加鎖的思路是,如果 key 不存在,將 key 設定為 value

如果 key 已存在,則 setnx 不做任何動作

1、 客戶端a請求伺服器設定key的值,如果設定成功就表示加鎖成功

2、 客戶端b也去請求伺服器設定key的值,如果返回失敗,那麼就代表加鎖失敗

3、 客戶端a執行**完成,刪除鎖

4、 客戶端b在等待一段時間後在去請求設定key的值,設定成功

5、 客戶端b執行**完成,刪除鎖

$redis->setnx($key, $value);

$redis->expire($key, $ttl);

第三種鎖set

上面兩種方法都有乙個問題,會發現,都需要設定 key 過期。那麼為什麼要設定key過期呢?如果請求執行因為某些原因意外退出了,導致建立了鎖但是沒有刪除鎖,那麼這個鎖將一直存在,以至於以後快取再也得不到更新。於是乎我們需要給鎖加乙個過期時間以防不測。

但是借助 expire 來設定就不是原子性操作了。所以還可以通過事務來確保原子性,但是還是有些問題,所以官方就引用了另外乙個,使用 set 命令本身已經從版本 2.6.12 開始包含了設定過期時間的功能。

1、 客戶端a請求伺服器設定key的值,如果設定成功就表示加鎖成功

2、 客戶端b也去請求伺服器設定key的值,如果返回失敗,那麼就代表加鎖失敗

3、 客戶端a執行**完成,刪除鎖

4、 客戶端b在等待一段時間後在去請求設定key的值,設定成功

5、 客戶端b執行**完成,刪除鎖

$redis->set($key, $value, array('nx', 'ex' => $ttl));  //ex表示秒
其它問題

雖然上面一步已經滿足了我們的需求,但是還是要考慮其它問題?

1、 redis發現鎖失敗了要怎麼辦?中斷請求還是迴圈請求?

2、 迴圈請求的話,如果有乙個獲取了鎖,其它的在去獲取鎖的時候,是不是容易發生搶鎖的可能?

3、 鎖提前過期後,客戶端a還沒執行完,然後客戶端b獲取到了鎖,這時候客戶端a執行完了,會不會在刪鎖的時候把b的鎖給刪掉?

解決辦法

針對問題1:使用迴圈請求,迴圈請求去獲取鎖

針對問題2:針對第二個問題,在迴圈請求獲取鎖的時候,加入睡眠功能,等待幾毫秒在執行迴圈

針對問題3:在加鎖的時候存入的key是隨機的。這樣的話,每次在刪除key的時候判斷下存入的key裡的value和自己存的是否一樣

do ', got 'eof' at end of input: … redis::del(key);

continue;//執行成功刪除key並跳出迴圈

}} else

} while(!$islock);

7. 另外乙個鎖

以上的鎖完全滿足了需求,但是官方另外還提供了一套加鎖的演算法,這裡以php為例

$servers = [

[『127.0.0.1』, 6379, 0.01],

[『127.0.0.1』, 6389, 0.01],

[『127.0.0.1』, 6399, 0.01],

];

$redlock = new redlock($servers);

//加鎖

$lock = $redlock->lock('my_resource_name', 1000);

//刪除鎖

$redlock->unlock($lock)

上面是官方提供的乙個加鎖方法,就是和第6的大體方法一樣,只不過官方寫的更健壯。所以可以直接使用官方提供寫好的類方法進行呼叫。官方提供了各種語言如何實現鎖。

分布式鎖文章:

redis實現分布式鎖

漫畫理解:

程式設計師小灰—《什麼是分布式鎖》

原文:

低併發下的加鎖問題

高併發下已有很多解決方案,說一說現公司在併發沒太高的實際場景下是怎樣控制併發問題的。首先,採用樂觀鎖的思想,在校驗時間戳或版本中選擇了時間戳,基本思想是 每次更新資料都會更新時間戳為當前系統時間,在更新資料前先將本地時間戳與資料庫裡存的時間戳對比一下,若時間戳一樣則證明沒人改過,可以進行更新操作,否...

springboot下redis高併發下的快取穿透

public responsebody string getclassesbyid pathvariable id integer id return redistemplate.opsforvalue get classes 從redis中拿 這樣看單機條件下沒有問題但是高併發下還是會存在多個使用...

高併發下的HashMap

1.hashmap在插入元素過多的時候需要進行resize,resize的條件是 hashmap.size capacity loadfactor。2.hashmap的resize包含擴容和rehash兩個步驟,rehash在併發的情況下可能會形成鍊錶環 hashmap進行儲存時,假設size超過當...