Redis分布式鎖的原理以及如何續期
擊水三千裡 2019-03-11 09:21:21
13909
收藏 29 分類專欄： Redis 面試 最後釋出:2019-03-11 09:21:21 首次釋出:2019-03-11 09:21:21 原文連結： https://mp.weixin.qq.com/s/RLeujAj5rwZGNYMD0uLbrg 版權
面試問題
Redis鎖的過期時間小于業務的執行時間該如何續期？
問題分析
首先如果你之前用Redis的分布式鎖的姿勢正确,并且看過相應的官方文檔的話,這個問題
So easy
.我們來看
很多同學在用分布式鎖時,都是直接百度搜尋找一個Redis分布式鎖工具類就直接用了，其實Redis分布式鎖比較正确的姿勢是采用
redisson
這個用戶端工具
如何回答
隻要用戶端一旦加鎖成功，就會啟動一個watch dog看門狗，他是一個背景線程，會每隔10秒檢查一下，如果用戶端還持有鎖key，那麼就會不斷的延長鎖key的生存時間。
預設情況下,加鎖的時間是30秒,.如果加鎖的業務沒有執行完,那麼到 30-10 = 20秒的時候,就會進行一次續期,把鎖重置成30秒.那這個時候可能又有同學問了,那業務的機器萬一當機了呢?當機了定時任務跑不了,就續不了期,那自然30秒之後鎖就解開了呗.
Redisson分布式鎖的底層原理
redisson實作Redis分布式鎖的底層原理
https://mp.weixin.qq.com/s/y_Uw3P2Ll7wvk_j5Fdlusw
1）加鎖機制
咱們來看上面那張圖，現在某個用戶端要加鎖。如果該用戶端面對的是一個redis cluster叢集，他首先會根據hash節點選擇一台機器。
這裡注意，僅僅隻是選擇一台機器！這點很關鍵！
緊接着，就會發送一段lua腳本到redis上，那段lua腳本如下所示：
為啥要用lua腳本呢？
因為一大坨複雜的業務邏輯，可以通過封裝在lua腳本中發送給redis，保證這段複雜業務邏輯執行的原子性。
那麼，這段lua腳本是什麼意思呢？
KEYS[1]代表的是你加鎖的那個key，比如說：
RLock lock = redisson.getLock("myLock");
這裡你自己設定了加鎖的那個鎖key就是“myLock”。
ARGV[1]代表的就是鎖key的預設生存時間，預設30秒。
ARGV[2]代表的是加鎖的用戶端的ID，類似于下面這樣：
8743c9c0-0795-4907-87fd-6c719a6b4586:1
給大家解釋一下，第一段if判斷語句，就是用“exists myLock”指令判斷一下，如果你要加鎖的那個鎖key不存在的話，你就進行加鎖。
如何加鎖呢？很簡單，用下面的指令：
hset myLock
8743c9c0-0795-4907-87fd-6c719a6b4586:1 1
通過這個指令設定一個hash資料結構，這行指令執行後，會出現一個類似下面的資料結構：
上述就代表“8743c9c0-0795-4907-87fd-6c719a6b4586:1”這個用戶端對“myLock”這個鎖key完成了加鎖。
接着會執行“pexpire myLock 30000”指令，設定myLock這個鎖key的生存時間是30秒。
好了，到此為止，ok，加鎖完成了。
（2）鎖互斥機制
那麼在這個時候，如果用戶端2來嘗試加鎖，執行了同樣的一段lua腳本，會咋樣呢？
很簡單，第一個if判斷會執行“exists myLock”，發現myLock這個鎖key已經存在了。
接着第二個if判斷，判斷一下，myLock鎖key的hash資料結構中，是否包含用戶端2的ID，但是明顯不是的，因為那裡包含的是用戶端1的ID。
是以，用戶端2會擷取到pttl myLock傳回的一個數字，這個數字代表了myLock這個鎖key的剩餘生存時間。比如還剩15000毫秒的生存時間。
此時用戶端2會進入一個while循環，不停的嘗試加鎖。
（3）watch dog自動延期機制
用戶端1加鎖的鎖key預設生存時間才30秒，如果超過了30秒，用戶端1還想一直持有這把鎖，怎麼辦呢？
簡單！隻要用戶端1一旦加鎖成功，就會啟動一個watch dog看門狗，他是一個背景線程，會每隔10秒檢查一下，如果用戶端1還持有鎖key，那麼就會不斷的延長鎖key的生存時間。
（4）可重入加鎖機制
那如果用戶端1都已經持有了這把鎖了，結果可重入的加鎖會怎麼樣呢？
比如下面這種代碼：
這時我們來分析一下上面那段lua腳本。
第一個if判斷肯定不成立，“exists myLock”會顯示鎖key已經存在了。
第二個if判斷會成立，因為myLock的hash資料結構中包含的那個ID，就是用戶端1的那個ID，也就是“8743c9c0-0795-4907-87fd-6c719a6b4586:1”
此時就會執行可重入加鎖的邏輯，他會用：
incrby myLock
8743c9c0-0795-4907-87fd-6c71a6b4586:1 1
通過這個指令，對用戶端1的加鎖次數，累加1。
此時myLock資料結構變為下面這樣：
大家看到了吧，那個myLock的hash資料結構中的那個用戶端ID，就對應着加鎖的次數
（5）釋放鎖機制
如果執行lock.unlock()，就可以釋放分布式鎖，此時的業務邏輯也是非常簡單的。
其實說白了，就是每次都對myLock資料結構中的那個加鎖次數減1。
如果發現加鎖次數是0了，說明這個用戶端已經不再持有鎖了，此時就會用：
“del myLock”指令，從redis裡删除這個key。
然後呢，另外的用戶端2就可以嘗試完成加鎖了。
這就是所謂的分布式鎖的開源Redisson架構的實作機制。
一般我們在生産系統中，可以用Redisson架構提供的這個類庫來基于redis進行分布式鎖的加鎖與釋放鎖。
（6）上述Redis分布式鎖的缺點
其實上面那種方案最大的問題，就是如果你對某個redis master執行個體，寫入了myLock這種鎖key的value，此時會異步複制給對應的master slave執行個體。
但是這個過程中一旦發生redis master當機，主備切換，redis slave變為了redis master。
接着就會導緻，用戶端2來嘗試加鎖的時候，在新的redis master上完成了加鎖，而用戶端1也以為自己成功加了鎖。
此時就會導緻多個用戶端對一個分布式鎖完成了加鎖。
這時系統在業務語義上一定會出現問題，導緻各種髒資料的産生。
是以這個就是redis cluster，或者是redis master-slave架構的主從異步複制導緻的redis分布式鎖的最大缺陷：在redis master執行個體當機的時候，可能導緻多個用戶端同時完成加鎖。
參考文章：
https://mp.weixin.qq.com/s/y_Uw3P2Ll7wvk_j5Fdlusw
相關文章：
https://mp.weixin.qq.com/s/RLeujAj5rwZGNYMD0uLbrg（每秒上千訂單場景下的分布式鎖高并發優化實踐）
面試問題
Redis鎖的過期時間小于業務的執行時間該如何續期？
問題分析
首先如果你之前用Redis的分布式鎖的姿勢正确,并且看過相應的官方文檔的話,這個問題
So easy
.我們來看
很多同學在用分布式鎖時,都是直接百度搜尋找一個Redis分布式鎖工具類就直接用了，其實Redis分布式鎖比較正确的姿勢是采用
redisson
這個用戶端工具
如何回答
隻要用戶端一旦加鎖成功，就會啟動一個watch dog看門狗，他是一個背景線程，會每隔10秒檢查一下，如果用戶端還持有鎖key，那麼就會不斷的延長鎖key的生存時間。
預設情況下,加鎖的時間是30秒,.如果加鎖的業務沒有執行完,那麼到 30-10 = 20秒的時候,就會進行一次續期,把鎖重置成30秒.那這個時候可能又有同學問了,那業務的機器萬一當機了呢?當機了定時任務跑不了,就續不了期,那自然30秒之後鎖就解開了呗.
Redisson分布式鎖的底層原理
redisson實作Redis分布式鎖的底層原理
https://mp.weixin.qq.com/s/y_Uw3P2Ll7wvk_j5Fdlusw
1）加鎖機制
咱們來看上面那張圖，現在某個用戶端要加鎖。如果該用戶端面對的是一個redis cluster叢集，他首先會根據hash節點選擇一台機器。
這裡注意，僅僅隻是選擇一台機器！這點很關鍵！
緊接着，就會發送一段lua腳本到redis上，那段lua腳本如下所示：
為啥要用lua腳本呢？
因為一大坨複雜的業務邏輯，可以通過封裝在lua腳本中發送給redis，保證這段複雜業務邏輯執行的原子性。
那麼，這段lua腳本是什麼意思呢？
KEYS[1]代表的是你加鎖的那個key，比如說：
RLock lock = redisson.getLock("myLock");
這裡你自己設定了加鎖的那個鎖key就是“myLock”。
ARGV[1]代表的就是鎖key的預設生存時間，預設30秒。
ARGV[2]代表的是加鎖的用戶端的ID，類似于下面這樣：
8743c9c0-0795-4907-87fd-6c719a6b4586:1
給大家解釋一下，第一段if判斷語句，就是用“exists myLock”指令判斷一下，如果你要加鎖的那個鎖key不存在的話，你就進行加鎖。
如何加鎖呢？很簡單，用下面的指令：
hset myLock
8743c9c0-0795-4907-87fd-6c719a6b4586:1 1
通過這個指令設定一個hash資料結構，這行指令執行後，會出現一個類似下面的資料結構：
上述就代表“8743c9c0-0795-4907-87fd-6c719a6b4586:1”這個用戶端對“myLock”這個鎖key完成了加鎖。
接着會執行“pexpire myLock 30000”指令，設定myLock這個鎖key的生存時間是30秒。
好了，到此為止，ok，加鎖完成了。
（2）鎖互斥機制
那麼在這個時候，如果用戶端2來嘗試加鎖，執行了同樣的一段lua腳本，會咋樣呢？
很簡單，第一個if判斷會執行“exists myLock”，發現myLock這個鎖key已經存在了。
接着第二個if判斷，判斷一下，myLock鎖key的hash資料結構中，是否包含用戶端2的ID，但是明顯不是的，因為那裡包含的是用戶端1的ID。
是以，用戶端2會擷取到pttl myLock傳回的一個數字，這個數字代表了myLock這個鎖key的剩餘生存時間。比如還剩15000毫秒的生存時間。
此時用戶端2會進入一個while循環，不停的嘗試加鎖。
（3）watch dog自動延期機制
用戶端1加鎖的鎖key預設生存時間才30秒，如果超過了30秒，用戶端1還想一直持有這把鎖，怎麼辦呢？
簡單！隻要用戶端1一旦加鎖成功，就會啟動一個watch dog看門狗，他是一個背景線程，會每隔10秒檢查一下，如果用戶端1還持有鎖key，那麼就會不斷的延長鎖key的生存時間。
（4）可重入加鎖機制
那如果用戶端1都已經持有了這把鎖了，結果可重入的加鎖會怎麼樣呢？
比如下面這種代碼：
這時我們來分析一下上面那段lua腳本。
第一個if判斷肯定不成立，“exists myLock”會顯示鎖key已經存在了。
第二個if判斷會成立，因為myLock的hash資料結構中包含的那個ID，就是用戶端1的那個ID，也就是“8743c9c0-0795-4907-87fd-6c719a6b4586:1”
此時就會執行可重入加鎖的邏輯，他會用：
incrby myLock
8743c9c0-0795-4907-87fd-6c71a6b4586:1 1
通過這個指令，對用戶端1的加鎖次數，累加1。
此時myLock資料結構變為下面這樣：
大家看到了吧，那個myLock的hash資料結構中的那個用戶端ID，就對應着加鎖的次數
（5）釋放鎖機制
如果執行lock.unlock()，就可以釋放分布式鎖，此時的業務邏輯也是非常簡單的。
其實說白了，就是每次都對myLock資料結構中的那個加鎖次數減1。
如果發現加鎖次數是0了，說明這個用戶端已經不再持有鎖了，此時就會用：
“del myLock”指令，從redis裡删除這個key。
然後呢，另外的用戶端2就可以嘗試完成加鎖了。
這就是所謂的分布式鎖的開源Redisson架構的實作機制。
一般我們在生産系統中，可以用Redisson架構提供的這個類庫來基于redis進行分布式鎖的加鎖與釋放鎖。
（6）上述Redis分布式鎖的缺點
其實上面那種方案最大的問題，就是如果你對某個redis master執行個體，寫入了myLock這種鎖key的value，此時會異步複制給對應的master slave執行個體。
但是這個過程中一旦發生redis master當機，主備切換，redis slave變為了redis master。
接着就會導緻，用戶端2來嘗試加鎖的時候，在新的redis master上完成了加鎖，而用戶端1也以為自己成功加了鎖。
此時就會導緻多個用戶端對一個分布式鎖完成了加鎖。
這時系統在業務語義上一定會出現問題，導緻各種髒資料的産生。
是以這個就是redis cluster，或者是redis master-slave架構的主從異步複制導緻的redis分布式鎖的最大缺陷：在redis master執行個體當機的時候，可能導緻多個用戶端同時完成加鎖。
參考文章：
https://mp.weixin.qq.com/s/y_Uw3P2Ll7wvk_j5Fdlusw
相關文章：
https://mp.weixin.qq.com/s/RLeujAj5rwZGNYMD0uLbrg（每秒上千訂單場景下的分布式鎖高并發優化實踐）