Last-Modified: 2019年5月10日15:31:41
參考鏈接
鎖實現的注意點
- 互斥: 任意時刻, 只能有一個客戶端獲得鎖
- 不會死鎖: 客戶端持有鎖期間崩潰, 沒有主動解除鎖, 能保證後續的其他客戶端獲得鎖
- 鎖歸屬標識: 加鎖和解鎖的必須是同一個客戶端, 客戶端不能解掉非自己持有的鎖(鎖應具備標識)
如果是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...
注意點:
- 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/re...
對應的翻譯: http://ifeve.com/redis-lock/
RedLock 算法
官方給出了一個 RedLock 算法
情景: 當前有N個完全獨立的Redis master節點, 分別部署在不同的主機上
客戶端獲取鎖的操作:
- 使用相同key和唯一值(作爲value)同時向這N個redis節點請求鎖, 鎖的超時時間應該 >> 超時時間(考慮到請求耗時), 若某個節點阻塞了了應儘快跳過
- 計算步驟1消耗的時間, 若總消耗時間超過超時時間, 則認爲鎖失敗. 客戶端需在大多數(超過一半)的節點上成功獲取鎖, 才認爲是鎖成功.
- 如果鎖成功了, 則該鎖有效時間就是 鎖原始有效時間 - 步驟1消耗的時間
- 如果鎖失敗了(超時或無法獲取超過一半 N/2 + 1 實例的鎖), 客戶端會到每個節點釋放鎖(是每個, 即使之前認爲加鎖失敗的節點)