鎖實現的注意點
- 互斥: 任意時刻, 只能有一個客戶端獲得鎖
- 不會死鎖: 客戶端持有鎖期間崩潰, 沒有主動解除鎖, 能保證后續的其他客戶端獲得鎖
- 鎖歸屬標識: 加鎖和解鎖的必須是同一個客戶端, 客戶端不能解掉非自己持有的鎖(鎖應具備標識)
如果是Redis集群, 還得考慮具有容錯性: 只要大部分Redis節點正常運行, 客戶端就可以加鎖和解鎖.
以下只考慮 Redis單機部署的 場景.
如果是Redis集群部署, 可以使用
加鎖
php 加鎖示例
$redis = new Redis();
$redis->pconnect("127.0.0.1", 6379);
$redis->auth("password"); // 密碼驗證
$redis->select(1); // 選擇所使用的數據庫, 默認有16個
$key = "...";
$value = "...";
$expire = 3;
// 參數解釋 ↓
// $value 加鎖的客戶端請求標識, 必須保證在所有獲取鎖清秋的客戶端里保持唯一, 滿足上面的第3個條件: 加鎖/解鎖的是同一客戶端
// "NX" 僅在key不存在時加鎖, 滿足條件1: 互斥型
// "EX" 設置鎖過期時間, 滿足條件2: 避免死鎖
$redis->set($key, $value, ["NX", "EX" => $expire])
執行上面代碼結果:
- $key 對應的鎖不存在, 進行加鎖操作
- $key 對應的鎖已存在, 什么也不做
加鎖容易錯誤的點:
-
使用
setnx和expire的組合原因: 若在
setnx后腳本崩潰會導致死鎖
$value 客戶端標識的:
- 簡單點就用 毫秒級unix時間戳 + 客戶端標識(大部分情況下夠用了)
- 使用其他算法確保生成唯一隨機值
connect 與 pconnect
在php中, 若使用 pconnect 連接redis, 則在當前腳本聲明周期結束后, 與redis建立的連接仍會保留, 直到對應fpm進程的生命周期結束, 同時在下一次請求時, fpm會重用該連接.
即該連接的生命周期是 fpm 進程的生命周期, 而非一次php腳本的執行.
若代碼使用 pconnect, close 的作用僅是使當前php腳本不能再進行redis請求, 並沒有真正關閉與redis的連接, 連接在后續請求中仍然會被重用.
pconnect函數在線程版本中不能被使用
解鎖
php解鎖示例: 使用lua腳本
$key = "...";
$identification = "...";
// KEYS 和 ARGV 是lua腳本中的全局變量
$script = <<< EOF
if redis.call("get", KEYS[1]) == ARGV[1] then
return redis.call("del", KEYS[1])
then
return 0
end
EOF;
# $result = $redis->eval($script, [$key, $identification], 1);
// 返回結果 >0 表示解鎖成功
// php中參數的傳遞順序與標准不一樣, 注意區分
// 第2個參數表示傳入的 KEYS 和 ARGV, 通過第3個參數來區分, KEYS 在前, ARGV 在后
// 第3個參數表示傳入的 KEYS 的個數
$result = $redis->evaluate($script, [$key, $identification], 1);
使用Lua腳本的原因:
-
避免誤刪其他客戶端加的鎖
eg. 某個客戶端獲取鎖后做其他操作過久導致鎖被自動釋放, 這時候要避免這個客戶端刪除已經被其他客戶端獲取的鎖, 這就用到了鎖的標識.
-
lua 腳本中執行
get和del是原子性的, 整個lua腳本會被當做一條命令來執行 -
即使
get后鎖剛好過期, 此時也不會被其他客戶端加鎖
eval命令執行Lua代碼的時候，Lua代碼將被當成一個命令去執行，並且直到eval命令執行完成，Redis才會執行其他命令。
由於 script 執行的原子性, 所以不要在script中執行過長開銷的程序，否則會驗證影響其它請求的執行。
解鎖容易錯誤的點:
-
直接
del刪除鍵原因: 可能移除掉其他客戶端加的鎖(在自己的鎖已過期情況下)
-
get判斷鎖歸屬, 若符合再del原因: 非原子性操作, 若在
get后鎖過期了, 此時別的客戶端進行加鎖操作, 這里的del就會錯誤的將其他客戶端加的鎖解開.
Redis 中使用 Lua 腳本的注意點
↓ 這一段內容轉載自 https://blog.csdn.net/zhouzme/article/details/53046606
注意點:
-
Redis 會把所有執行過的腳本都緩存在內存中
-
Redis 在重啟的時候會釋放掉之前保存的腳本
-
Lua 腳本中所需要用到的鍵名以及參數一定要使用 KEYS 和 ARGV 來替換，千萬不要寫死在代碼中，除非你百分百確定每次請求時他們是固定不變的值，特別是涉及到 時間，隨機數的，一定要用參數代入，因為 Redis 每次使用 script 都會校驗腳本緩存中是否已存在相同腳本，否則就會存儲到緩存中，如果你的腳本很長，且每次請求存在不同的變量值，則會生成無數多個腳本緩存，你將會發現Redis占用的內存會唰唰唰的往上漲，我一開始因為key 和 參數太多，分開寫太麻煩了，就圖省事方便，直接把變量拼接到腳本里面，結果發現內存不停的漲，很是抓狂，找了好久才發現是這么個原因。
-
Lua 中腳本定義變量一定要使用局部變量, 即
local var = 1, 局部變量只在所定義的塊(指控制結構, 函數或chunk等)內有效, 使用局部變量可以避免命名沖突 並且訪問更快(lua中局部變量和全局變量存儲方式是不一樣的) -
如果Lua腳本寫的比較長，非本地或局域網的情況下，建議使用 SHA 簽名的方法來調用，這樣節省帶寬，但對性能似乎沒什么直接的提升。這里對小白普及下我理解的原理就是 Redis 會把每個腳本都生成唯一簽名，把腳本作為函數體，並使用該簽名作為腳本的函數名放到緩存中，所以后面調用就只需要傳一個 SHA 簽名就可以調用該函數了，精簡很多了。同一個腳本生成的簽名都是相同的，所以SHA簽名可以先在本地生成，然后在服務器上 script load 一次腳本，程序中只需保存和使用該簽名即可。另外需要注意的是，腳本如果被改動哪怕一個換行或一個空格（這些容易被忽略或誤操作）都必須重新 load 來獲取新的 SHA
注意：獲取 SHA 簽名是單獨的功能，不要放在你的正常流程中，當本地開發時就可以生成SHA，把字符串寫死在流程中。同樣的腳本，Reids是始終生成相同的簽名的。
-
通過 eval 帶入的 ARGV 參數如果原來是數字的，會被轉換為字符串，如果你的邏輯中需要判斷該變量 > 0 或 < 0 之類的數字判斷則必須進行字符串到數字的轉換，使用
tonumber()方法if (tonumber(ARGV[1]) > 0) then return 1; end; -
我測試了幾個 lua script 與 PIPELINE 處理對比，發現 script 的效率一般比 PIPELINE 高 30% ~ 40% 左右
Redis集群分布式鎖
Redis 集群相對單機來說, 需要考慮一個 容錯性, 設計上更為復雜
由於這個我也從未實踐過, 先貼一個官方的教程貼壓壓驚
https://github.com/antirez/redis-doc/blob/master/topics/distlock.md
對應的翻譯: http://ifeve.com/redis-lock/
RedLock 算法
官方給出了一個 RedLock 算法
情景: 當前有N個完全獨立的Redis master節點, 分別部署在不同的主機上
客戶端獲取鎖的操作:
- 使用相同key和唯一值(作為value)同時向這N個redis節點請求鎖, 鎖的超時時間應該 >> 超時時間(考慮到請求耗時), 若某個節點阻塞了了應盡快跳過
- 計算步驟1消耗的時間, 若總消耗時間超過超時時間, 則認為鎖失敗. 客戶端需在大多數(超過一半)的節點上成功獲取鎖, 才認為是鎖成功.
- 如果鎖成功了, 則該鎖有效時間就是 鎖原始有效時間 - 步驟1消耗的時間
- 如果鎖失敗了(超時或無法獲取超過一半 N/2 + 1 實例的鎖), 客戶端會到每個節點釋放鎖(是每個, 即使之前認為加鎖失敗的節點)