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

2021-10-14 12:58:21 字數 2074 閱讀 6602

setnx,是set if not exists 的縮寫,也就是只有不存在的時候才設定, 設定成功時返回 1 , 設定失敗時返回 0 。可以利用它來實現鎖的效果,但是很多人在使用的過程中都有一些問題沒有考慮到。

例如某個查詢資料庫的介面因為請求量比較大所以加了快取,並設定快取過期後重新整理。當併發量比較大並且快取過期的瞬間,大量併發請求會直接查詢資料庫導致雪崩。如果使用鎖機制來控制只有乙個請求去更新快取就能避免雪崩的問題。下面是很多人下意識想到的加鎖方法

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

if($rs)

通過 setnx 獲取鎖,如果成功了則更新快取然後刪除鎖。其實這裡有乙個嚴重的問題:如果更新快取的時候因為某些原因意外退出了,那麼這個鎖就不會被刪除而一直存在,以至於快取再也得不到更新。為了解決這個問題有人可能會想到給鎖設定乙個過期時間,如下

$redis->multi();

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

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

$redis->exec();

因為 setnx 不具備設定過期時間的功能,所以要借助 expire 來設定,同時需要使用 multi/exec 來確保請求的原子性,以免 setnx 成功了 expire 卻失敗了。這樣還有問題:當多個請求到達時,雖然只有乙個請求的 setnx 可以成功,但是任何乙個請求的 expire 卻都可以成功,這就意味著即便獲取不到鎖也可以重新整理過期時間,導致鎖一直有效,還是解決不了上面的問題。顯然 setnx 滿足不了需求,redis從 2.6.12 起,set 涵蓋了 setex 的功能, set 本身又包含了設定過期時間的功能,所以使用 set 就可以解決上面遇到的問題

$rs=$redis->set($key,$value,array('nx','ex'=>$ttl));

if($rs)

到這一步其實還是有問題的,如果乙個請求更新快取的時間比鎖的有效期還要長,導致在快取更新過程中鎖就失效了,此時另乙個請求就會獲取到鎖,但前乙個請求在快取更新完畢的時候,直接刪除鎖的話就會出現誤刪其它請求建立的鎖的情況。所以要避免這種問題,可以在建立鎖的時候需要引入乙個隨機值並在刪除鎖的時候加以判斷

$rs=$redis->set($key,$random,array('nx','ex'=>$ttl));

if($rs)

}

正確地使用Checked Exception

正確地使用checked exception 實際上,如何正確地使用checked exception已經在前面的各章節講解中進行了詳細地說明。在這裡我們再次做乙個總結,同時也用來加深一下印象。從api編寫者的角度來講,他所需要考慮的就是在何時使用乙個checked exception。首先,che...

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

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

正確地啟動hadoop

環境 ubuntu16.04系統 64位 apache hive 3.0.0 bin spark 2.3.1 bin hadoop2.7 scala2.11 hosts配置 etc hosts中注意hostname不要和127.0.0.1繫結 219.223.207.228 ubuntu 127.0...