這篇文章主要講解了“redis分布式鎖的實(shí)現(xiàn)原理介紹”，文中的講解內(nèi)容簡(jiǎn)單清晰，易于學(xué)習(xí)與理解，下面請(qǐng)大家跟著小編的思路慢慢深入，一起來研究和學(xué)習(xí)“Redis分布式鎖的實(shí)現(xiàn)原理介紹”吧！

創(chuàng)新互聯(lián)服務(wù)項(xiàng)目包括堆龍德慶網(wǎng)站建設(shè)、堆龍德慶網(wǎng)站制作、堆龍德慶網(wǎng)頁制作以及堆龍德慶網(wǎng)絡(luò)營(yíng)銷策劃等。多年來，我們專注于互聯(lián)網(wǎng)行業(yè)，利用自身積累的技術(shù)優(yōu)勢(shì)、行業(yè)經(jīng)驗(yàn)、深度合作伙伴關(guān)系等，向廣大中小型企業(yè)、政府機(jī)構(gòu)等提供互聯(lián)網(wǎng)行業(yè)的解決方案，堆龍德慶網(wǎng)站推廣取得了明顯的社會(huì)效益與經(jīng)濟(jì)效益。目前，我們服務(wù)的客戶以成都為中心已經(jīng)輻射到堆龍德慶省份的部分城市，未來相信會(huì)繼續(xù)擴(kuò)大服務(wù)區(qū)域并繼續(xù)獲得客戶的支持與信任！

一、寫在前面

現(xiàn)在面試，一般都會(huì)聊聊分布式系統(tǒng)這塊的東西。通常面試官都會(huì)從服務(wù)框架（Spring Cloud、Dubbo）聊起，一路聊到分布式事務(wù)、分布式鎖、ZooKeeper等知識(shí)。

所以咱們這篇文章就來聊聊分布式鎖這塊知識(shí)，具體的來看看Redis分布式鎖的實(shí)現(xiàn)原理。

說實(shí)話，如果在公司里落地生產(chǎn)環(huán)境用分布式鎖的時(shí)候，一定是會(huì)用開源類庫的，比如Redis分布式鎖，一般就是用Redisson框架就好了，非常的簡(jiǎn)便易用。

大家如果有興趣，可以去看看Redisson的官網(wǎng)，看看如何在項(xiàng)目中引入Redisson的依賴，然后基于Redis實(shí)現(xiàn)分布式鎖的加鎖與釋放鎖。

下面給大家看一段簡(jiǎn)單的使用代碼片段，先直觀的感受一下：

怎么樣，上面那段代碼，是不是感覺簡(jiǎn)單的不行！

此外，人家還支持redis單實(shí)例、redis哨兵、redis cluster、redis master-slave等各種部署架構(gòu)，都可以給你完美實(shí)現(xiàn)。

二、Redisson實(shí)現(xiàn)Redis分布式鎖的底層原理

好的，接下來就通過一張手繪圖，給大家說說Redisson這個(gè)開源框架對(duì)Redis分布式鎖的實(shí)現(xiàn)原理。

（1）加鎖機(jī)制

咱們來看上面那張圖，現(xiàn)在某個(gè)客戶端要加鎖。如果該客戶端面對(duì)的是一個(gè)redis cluster集群，他首先會(huì)根據(jù)hash節(jié)點(diǎn)選擇一臺(tái)機(jī)器。

這里注意，僅僅只是選擇一臺(tái)機(jī)器！這點(diǎn)很關(guān)鍵！

緊接著，就會(huì)發(fā)送一段lua腳本到redis上，那段lua腳本如下所示：

為啥要用lua腳本呢？

因?yàn)橐淮筵鐝?fù)雜的業(yè)務(wù)邏輯，可以通過封裝在lua腳本中發(fā)送給redis，保證這段復(fù)雜業(yè)務(wù)邏輯執(zhí)行的原子性。

那么，這段lua腳本是什么意思呢？

KEYS[1]代表的是你加鎖的那個(gè)key，比如說：

RLock lock = redisson.getLock("myLock");

這里你自己設(shè)置了加鎖的那個(gè)鎖key就是“myLock”。

ARGV[1]代表的就是鎖key的默認(rèn)生存時(shí)間，默認(rèn)30秒。

ARGV[2]代表的是加鎖的客戶端的ID，類似于下面這樣：

8743c9c0-0795-4907-87fd-6c719a6b4586:1

給大家解釋一下，第一段if判斷語句，就是用“exists myLock”命令判斷一下，如果你要加鎖的那個(gè)鎖key不存在的話，你就進(jìn)行加鎖。

如何加鎖呢？很簡(jiǎn)單，用下面的命令：

hset myLock

8743c9c0-0795-4907-87fd-6c719a6b4586:1 1

通過這個(gè)命令設(shè)置一個(gè)hash數(shù)據(jù)結(jié)構(gòu)，這行命令執(zhí)行后，會(huì)出現(xiàn)一個(gè)類似下面的數(shù)據(jù)結(jié)構(gòu)：

上述就代表“8743c9c0-0795-4907-87fd-6c719a6b4586:1”這個(gè)客戶端對(duì)“myLock”這個(gè)鎖key完成了加鎖。

接著會(huì)執(zhí)行“pexpire myLock 30000”命令，設(shè)置myLock這個(gè)鎖key的生存時(shí)間是30秒。

好了，到此為止，ok，加鎖完成了。

（2）鎖互斥機(jī)制

那么在這個(gè)時(shí)候，如果客戶端2來嘗試加鎖，執(zhí)行了同樣的一段lua腳本，會(huì)咋樣呢？

很簡(jiǎn)單，第一個(gè)if判斷會(huì)執(zhí)行“exists myLock”，發(fā)現(xiàn)myLock這個(gè)鎖key已經(jīng)存在了。

接著第二個(gè)if判斷，判斷一下，myLock鎖key的hash數(shù)據(jù)結(jié)構(gòu)中，是否包含客戶端2的ID，但是明顯不是的，因?yàn)槟抢锇氖强蛻舳?的ID。

所以，客戶端2會(huì)獲取到pttl myLock返回的一個(gè)數(shù)字，這個(gè)數(shù)字代表了myLock這個(gè)鎖key的剩余生存時(shí)間。比如還剩15000毫秒的生存時(shí)間。

此時(shí)客戶端2會(huì)進(jìn)入一個(gè)while循環(huán)，不停的嘗試加鎖。

（3）watch dog自動(dòng)延期機(jī)制

客戶端1加鎖的鎖key默認(rèn)生存時(shí)間才30秒，如果超過了30秒，客戶端1還想一直持有這把鎖，怎么辦呢？

簡(jiǎn)單！只要客戶端1一旦加鎖成功，就會(huì)啟動(dòng)一個(gè)watch dog看門狗，他是一個(gè)后臺(tái)線程，會(huì)每隔10秒檢查一下，如果客戶端1還持有鎖key，那么就會(huì)不斷的延長(zhǎng)鎖key的生存時(shí)間。

（4）可重入加鎖機(jī)制

那如果客戶端1都已經(jīng)持有了這把鎖了，結(jié)果可重入的加鎖會(huì)怎么樣呢？

比如下面這種代碼：

這時(shí)我們來分析一下上面那段lua腳本。

第一個(gè)if判斷肯定不成立，“exists myLock”會(huì)顯示鎖key已經(jīng)存在了。

第二個(gè)if判斷會(huì)成立，因?yàn)閙yLock的hash數(shù)據(jù)結(jié)構(gòu)中包含的那個(gè)ID，就是客戶端1的那個(gè)ID，也就是“8743c9c0-0795-4907-87fd-6c719a6b4586:1”

此時(shí)就會(huì)執(zhí)行可重入加鎖的邏輯，他會(huì)用：

incrby myLock

8743c9c0-0795-4907-87fd-6c71a6b4586:1 1

通過這個(gè)命令，對(duì)客戶端1的加鎖次數(shù)，累加1。

此時(shí)myLock數(shù)據(jù)結(jié)構(gòu)變?yōu)橄旅孢@樣：

大家看到了吧，那個(gè)myLock的hash數(shù)據(jù)結(jié)構(gòu)中的那個(gè)客戶端ID，就對(duì)應(yīng)著加鎖的次數(shù)

（5）釋放鎖機(jī)制

如果執(zhí)行l(wèi)ock.unlock()，就可以釋放分布式鎖，此時(shí)的業(yè)務(wù)邏輯也是非常簡(jiǎn)單的。

其實(shí)說白了，就是每次都對(duì)myLock數(shù)據(jù)結(jié)構(gòu)中的那個(gè)加鎖次數(shù)減1。

如果發(fā)現(xiàn)加鎖次數(shù)是0了，說明這個(gè)客戶端已經(jīng)不再持有鎖了，此時(shí)就會(huì)用：

“del myLock”命令，從redis里刪除這個(gè)key。

然后呢，另外的客戶端2就可以嘗試完成加鎖了。

這就是所謂的分布式鎖的開源Redisson框架的實(shí)現(xiàn)機(jī)制。

一般我們?cè)谏a(chǎn)系統(tǒng)中，可以用Redisson框架提供的這個(gè)類庫來基于redis進(jìn)行分布式鎖的加鎖與釋放鎖。

（6）上述Redis分布式鎖的缺點(diǎn)

其實(shí)上面那種方案最大的問題，就是如果你對(duì)某個(gè)redis master實(shí)例，寫入了myLock這種鎖key的value，此時(shí)會(huì)異步復(fù)制給對(duì)應(yīng)的master slave實(shí)例。

但是這個(gè)過程中一旦發(fā)生redis master宕機(jī)，主備切換，redis slave變?yōu)榱藃edis master。

接著就會(huì)導(dǎo)致，客戶端2來嘗試加鎖的時(shí)候，在新的redis master上完成了加鎖，而客戶端1也以為自己成功加了鎖。

此時(shí)就會(huì)導(dǎo)致多個(gè)客戶端對(duì)一個(gè)分布式鎖完成了加鎖。

這時(shí)系統(tǒng)在業(yè)務(wù)語義上一定會(huì)出現(xiàn)問題，導(dǎo)致各種臟數(shù)據(jù)的產(chǎn)生。

所以這個(gè)就是redis cluster，或者是redis master-slave架構(gòu)的主從異步復(fù)制導(dǎo)致的redis分布式鎖的最大缺陷：在redis master實(shí)例宕機(jī)的時(shí)候，可能導(dǎo)致多個(gè)客戶端同時(shí)完成加鎖。

感謝各位的閱讀，以上就是“Redis分布式鎖的實(shí)現(xiàn)原理介紹”的內(nèi)容了，經(jīng)過本文的學(xué)習(xí)后，相信大家對(duì)Redis分布式鎖的實(shí)現(xiàn)原理介紹這一問題有了更深刻的體會(huì)，具體使用情況還需要大家實(shí)踐驗(yàn)證。這里是創(chuàng)新互聯(lián)，小編將為大家推送更多相關(guān)知識(shí)點(diǎn)的文章，歡迎關(guān)注！