建站
咨詢
售后
建站咨詢
新聞中心
寫在前面
現(xiàn)在面試，一般都會聊聊分布式系統(tǒng)這塊的東西。通常面試官都會從服務框架（Spring Cloud、Dubbo）聊起，一路聊到分布式事務、分布式鎖、ZooKeeper等知識。
所以咱們這篇文章就來聊聊分布式鎖這塊知識，具體的來看看Redis分布式鎖的實現(xiàn)原理。
說實話，如果在公司里落地生產環(huán)境用分布式鎖的時候，一定是會用開源類庫的，比如Redis分布式鎖，一般就是用Redisson框架就好了，非常的簡便易用。
大家如果有興趣，可以去看看Redisson的官網，看看如何在項目中引入Redisson的依賴，然后基于Redis實現(xiàn)分布式鎖的加鎖與釋放鎖。
下面給大家看一段簡單的使用代碼片段，先直觀的感受一下：
怎么樣，上面那段代碼，是不是感覺簡單的不行！
此外，人家還支持redis單實例、redis哨兵、redis cluster、redis master-slave等各種部署架構，都可以給你完美實現(xiàn)。
Redisson實現(xiàn)Redis分布式鎖的底層原理
好的，接下來就通過一張手繪圖，給大家說說Redisson這個開源框架對Redis分布式鎖的實現(xiàn)原理。
（1）加鎖機制
咱們來看上面那張圖，現(xiàn)在某個客戶端要加鎖。如果該客戶端面對的是一個redis cluster集群，他首先會根據(jù)hash節(jié)點選擇一臺機器。
這里注意，僅僅只是選擇一臺機器！這點很關鍵！
緊接著，就會發(fā)送一段lua腳本到redis上，那段lua腳本如下所示：
為啥要用lua腳本呢？
因為一大坨復雜的業(yè)務邏輯，可以通過封裝在lua腳本中發(fā)送給redis，保證這段復雜業(yè)務邏輯執(zhí)行的原子性。
那么，這段lua腳本是什么意思呢？
KEYS[1]代表的是你加鎖的那個key，比如說：
這里你自己設置了加鎖的那個鎖key就是“myLock”。
RLock lock = redisson.getLock("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數(shù)據(jù)結構，這行命令執(zhí)行后，會出現(xiàn)一個類似下面的數(shù)據(jù)結構：
上述就代表“8743c9c0-0795-4907-87fd-6c719a6b4586:1”這個客戶端對“myLock”這個鎖key完成了加鎖。
接著會執(zhí)行“pexpire myLock 30000”命令，設置myLock這個鎖key的生存時間是30秒。
好了，到此為止，ok，加鎖完成了。
（2）鎖互斥機制
那么在這個時候，如果客戶端2來嘗試加鎖，執(zhí)行了同樣的一段lua腳本，會咋樣呢？
很簡單，第一個if判斷會執(zhí)行“exists myLock”，發(fā)現(xiàn)myLock這個鎖key已經存在了。
接著第二個if判斷，判斷一下，myLock鎖key的hash數(shù)據(jù)結構中，是否包含客戶端2的ID，但是明顯不是的，因為那里包含的是客戶端1的ID。
所以，客戶端2會獲取到pttl myLock返回的一個數(shù)字，這個數(shù)字代表了myLock這個鎖key的剩余生存時間。比如還剩15000毫秒的生存時間。
此時客戶端2會進入一個while循環(huán)，不停的嘗試加鎖。
（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數(shù)據(jù)結構中包含的那個ID，就是客戶端1的那個ID，也就是“8743c9c0-0795-4907-87fd-6c719a6b4586:1”。
此時就會執(zhí)行可重入加鎖的邏輯，他會用：
incrby myLock
8743c9c0-0795-4907-87fd-6c71a6b4586:1 1
通過這個命令，對客戶端1的加鎖次數(shù)，累加1。
此時myLock數(shù)據(jù)結構變?yōu)橄旅孢@樣：
大家看到了吧，那個myLock的hash數(shù)據(jù)結構中的那個客戶端ID，就對應著加鎖的次數(shù)。
（5）釋放鎖機制
如果執(zhí)行l(wèi)ock.unlock()，就可以釋放分布式鎖，此時的業(yè)務邏輯也是非常簡單的。
其實說白了，就是每次都對myLock數(shù)據(jù)結構中的那個加鎖次數(shù)減1。
如果發(fā)現(xiàn)加鎖次數(shù)是0了，說明這個客戶端已經不再持有鎖了，此時就會用：
“del myLock”命令，從redis里刪除這個key。
然后呢，另外的客戶端2就可以嘗試完成加鎖了。
這就是所謂的分布式鎖的開源Redisson框架的實現(xiàn)機制。
一般我們在生產系統(tǒng)中，可以用Redisson框架提供的這個類庫來基于redis進行分布式鎖的加鎖與釋放鎖。
（6）上述Redis分布式鎖的缺點
其實上面那種方案最大的問題，就是如果你對某個redis master實例，寫入了myLock這種鎖key的value，此時會異步復制給對應的master slave實例。
但是這個過程中一旦發(fā)生redis master宕機，主備切換，redis slave變?yōu)榱藃edis master。
接著就會導致，客戶端2來嘗試加鎖的時候，在新的redis master上完成了加鎖，而客戶端1也以為自己成功加了鎖。
此時就會導致多個客戶端對一個分布式鎖完成了加鎖。
這時系統(tǒng)在業(yè)務語義上一定會出現(xiàn)問題，導致各種臟數(shù)據(jù)的產生。
所以這個就是redis cluster，或者是redis master-slave架構的主從異步復制導致的redis分布式鎖的最大缺陷：在redis master實例宕機的時候，可能導致多個客戶端同時完成加鎖。
網站標題：Redis分布式鎖，沒它真不行
文章起源：http://m.5511xx.com/article/cdhjsgs.html
