HotFrameLearning(簡稱 HFL) Redis_12_redis分布式鎖的3種實現方式

-

一、大致介紹

```

1、昨天介紹完redis的數據結構后，有小伙伴讓本人講講redis的分布式鎖，因此才有了此篇的由來，只是把我的節奏提前了而已；

2、接下來我就通過幾種方式介紹一下分布式鎖的使用；

```

二、源碼分享

2.1 獲取redis鎖且快速失敗

圖1 - 獲取redis鎖且快速失敗

```

1、圖1中，我們首先區分的是單機模式還是集群模式；

2、通過簡單的 set 操作，但是要注意一點，set 時需要設置 expiryTimeMills 超時時間，而且設置key與設置expiryTimeMills需要是在一條原子語句里面，如果不是的話則會引起不必要的死鎖問題；

3、至于為什么會引起死鎖，假設 set key 與 set expiryTimeMills 是兩條代碼語句，當 set key 成功后，程序立馬宕機了，那么這個 key 就沒有失效時間，相當于永久有效，那么下次再次競爭獲取該 key 時就永遠都是失敗的，因此要特別注意key與expiryTimeMills需要在同一條原子語句里面被執行；

4、當時又有人說，嘗試一次就失敗了，豈不是太不讓調用方省心了，調用方想嘗試多次還得自己寫個代碼玩玩，因此就有了下面嘗試多次獲取鎖的操作；

```

2.2 嘗試數次獲取鎖，獲取不到則返回失敗

圖2 - 嘗試數次獲取鎖，獲取不到則返回失敗

```

1、圖2中，同樣我們首先區分的是單機模式還是集群模式；

2、通過在 tryLockFailFast 外面再套一層 while 循環處理，讓入參多傳入嘗試次數retryTimes、嘗試間隔時間retryIntervalMills 兩個字段，即可滿足多次嘗試獲取鎖的訴求，這樣調用方就能省心了；

3、雖然加鎖是完事了，但是解鎖呢，是不是直接刪掉就完事了呢？請接著看~

```

2.3 釋放redis鎖且快速失敗

圖3 - 釋放redis鎖且快速失敗

```

1、圖3中，同樣我們首先區分的是單機模式還是集群模式；

2、只是在解鎖的時候，有點點不同，我們需要先看看我們解鎖的key對應的內存值是不是我們當初加鎖的那個入參值？

3、為什么要這么判斷呢？原因就是假設A線程加鎖了，但是A的任務還沒有執行完，此時key超時過期了，然后B線程又成功搶到了該鎖，但是當B前腳搶到鎖后A后腳就執行完了任務準備釋放鎖，那么就會將B已經獲取到的鎖釋放掉，這么一操作已不是把不該釋放的釋放了，最終都會導致相應業務功能執行出問題的；

4、因此才會在解鎖的時候，看下鎖對應的值是不是當初加鎖的那個值，如果一致則刪除，否則刪除失敗；

5、但是這么一連串的 get del 是兩個命令語句，但是解鎖的真實訴求需要保證原子性，因此我們就需要 redis 給我們提供的 lua 腳本原子性執行多個命令語句；

6、但是但是，說到這，又會有小伙伴會問，怕擔心任務執行太久導致redis超時，有啥好的方式處理呢？接著看~

```

2.4 阻塞獲取redisson鎖

圖4 - 阻塞獲取redisson鎖

```

1、圖4中，用的redisson框架版本號為 redisson-3.11.2.jar，具體maven坐標大家去中央倉庫看吧；

2、大家會想，這個redisson和之前的 tryUnLockFailFast 的加鎖有啥區別呢？不也是執行加鎖么？

3、答案當然不一樣，redisson 底層會有一個續命線程，每到過期時間的的1/3時就自動重新將過期時間置為入參的過期時間值，所以即使業務線程的任務執行很久，也不會因為鎖自動過期一事而煩惱，豈不快哉；

```

2.5 redisson知識擴展

圖5 - redisson知識擴展

```

1、圖5中，我們稍微多看一眼 redisson 框架，然后我們會發現底層提供了很多的鎖操作；

2、然而稍微再認真的同學仔細看看，會發現我們 JUC 有的類，這里都差不多實現了一番，可見 redisson 為分布式做了很多封裝，方便調用方盡情的使用；

```

歡迎關注+點贊，您的肯定是對我最大的支持!!!

總結

以上是生活随笔為你收集整理的为什么多个线程不可能同时抢到一把锁_HFL Redis_12_redis分布式锁的3种实现方式...的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。