摘要：由于執行的原子性所以不要在中執行過長開銷的程序，否則會驗證影響其它請求的執行。同一個腳本生成的簽名都是相同的，所以簽名可以先在本地生成，然后在服務器上一次腳本，程序中只需保存和使用該簽名即可。同樣的腳本，是始終生成相同的簽名的。

Last-Modified: 2019年6月5日15:59:34

PHP使用Redis+Lua腳本操作的注意事項

《Redis官方文檔》用Redis構建分布式鎖

互斥: 任意時刻, 只能有一個客戶端獲得鎖

不會死鎖: 客戶端持有鎖期間崩潰, 沒有主動解除鎖, 能保證后續的其他客戶端獲得鎖

鎖歸屬標識: 加鎖和解鎖的必須是同一個客戶端, 客戶端不能解掉非自己持有的鎖(鎖應具備標識)

如果是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時間戳 + 客戶端標識(大部分情況下夠用了)

使用其他算法確保生成唯一隨機值

在php中, 若使用 pconnect 連接redis, 則在當前腳本聲明周期結束后, 與redis建立的連接仍會保留, 直到對應fpm進程的生命周期結束, 同時在下一次請求時, fpm會重用該連接.

即該連接的生命周期是 fpm 進程的生命周期, 而非一次php腳本的執行.

若代碼使用 pconnect, close 的作用僅是使當前php腳本不能再進行redis請求, 并沒有真正關閉與redis的連接, 連接在后續請求中仍然會被重用.

pconnect函數在線程版本中不能被使用

上圖中, php-fpm 與redis建立的連接并未隨請求結束后馬上斷開

php解鎖示例: 使用lua腳本

$key = "...";
$identification = "...";
// KEYS 和 ARGV 是lua腳本中的全局變量
$script = <<< EOF
if redis.call("get", KEYS[1]) == ARGV[1] then
    return redis.call("del", KEYS[1])
else
    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 就會錯誤的將其他客戶端加的鎖解開.

↓ 這一段內容轉載自 https://blog.csdn.net/zhouzme...

注意點:

Redis 會把所有執行過的腳本都緩存在內存中

Redis 在重啟的時候會釋放掉之前保存的腳本

Lua 腳本中所需要用到的鍵名以及參數一定要使用 KEYS 和 ARGV 來替換，千萬不要寫死在代碼中，除非你百分百確定每次請求時他們是固定不變的值，特別是涉及到 時間，隨機數的，一定要用參數代入，因為 Redis 每次使用 script 都會校驗腳本緩存中是否已存在相同腳本，否則就會存儲到緩存中，如果你的腳本很長，且每次請求存在不同的變量值，則會生成無數多個腳本緩存，你將會發現Redis占用的內存會唰唰唰的往上漲，我一開始因為key 和 參數太多，分開寫太麻煩了，就圖省事方便，直接把變量拼接到腳本里面，結果發現內存不停的漲，很是抓狂，找了好久才發現是這么個原因。

義變量一定要使用局部變量, 即 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 集群相對單機來說, 需要考慮一個 容錯性, 設計上更為復雜

由于這個我也從未實踐過, 先貼一個官方的教程貼壓壓驚

https://github.com/antirez/re...

對應的翻譯: http://ifeve.com/redis-lock/

官方給出了一個 RedLock 算法

情景: 當前有N個完全獨立的Redis master節點, 分別部署在不同的主機上

客戶端獲取鎖的操作:

使用相同key和唯一值(作為value)同時向這N個redis節點請求鎖, 鎖的超時時間應該 >> 超時時間(考慮到請求耗時), 若某個節點阻塞了了應盡快跳過

計算步驟1消耗的時間, 若總消耗時間超過超時時間, 則認為鎖失敗. 客戶端需在大多數(超過一半)的節點上成功獲取鎖, 才認為是鎖成功.

如果鎖成功了, 則該鎖有效時間就是 鎖原始有效時間 - 步驟1消耗的時間

如果鎖失敗了(超時或無法獲取超過一半 N/2 + 1 實例的鎖), 客戶端會到每個節點釋放鎖(是每個, 即使之前認為加鎖失敗的節點)