分佈式鎖中的王者方案 - Redisson
作者 | 悟空聊架構
來源 | 悟空聊架構(ID:PassJava666)
轉載請聯繫授權(微信 ID:PassJava)
上篇講解了如何用 Redis 實現分佈式鎖的五種方案,但我們還是有更優的王者方案,就是用 Redisson。
緩存系列文章彙總:
緩存實戰(一):20 圖 |6 千字|緩存實戰
緩存實戰(二):Redis 分佈式鎖|從青銅到鑽石的五種演進方案
我們先來看下 Redis 官網對分佈式鎖的說法:
而 Java 版的 分佈式鎖的框架就是 Redisson。
本篇實戰內容將會基於我的開源項目 PassJava 來整合 Redisson。
我把後端
、前端
、小程序
都上傳到同一個倉庫裏面了,大家可以通過 Github
或 碼雲
訪問。地址如下:
Github: https://github.com/Jackson0714/PassJava-Platform
碼雲:https://gitee.com/jayh2018/PassJava-Platform
配套教程:www.passjava.cn
在實戰之前,我們先來看下使用 Redisson 的原理。
一、Redisson 是什麼?
如果你之前是在用 Redis 的話,那使用 Redisson 的話將會事半功倍,Redisson 提供了使用 Redis 的最簡單和最便捷的方法。
Redisson 的宗旨是促進使用者對 Redis 的關注分離(Separation of Concern),從而讓使用者能夠將精力更集中地放在處理業務邏輯上。
Redisson 是一個在 Redis 的基礎上實現的 Java 駐內存數據網格(In-Memory Data Grid)。
-
Netty 框架:Redisson 採用了基於 NIO 的 Netty 框架,不僅能作爲 Redis 底層驅動客戶端,具備提供對 Redis 各種組態形式的連接功能,對 Redis 命令能以同步發送、異步形式發送、異步流形式發送或管道形式發送的功能,LUA 腳本執行處理,以及處理返回結果的功能
-
基礎數據結構:將原生的 Redis
Hash
,List
,Set
,String
,Geo
,HyperLogLog
等數據結構封裝爲 Java 裏大家最熟悉的映射(Map)
,列表(List)
,集(Set)
,通用對象桶(Object Bucket)
,地理空間對象桶(Geospatial Bucket)
,基數估計算法(HyperLogLog)
等結構, -
分佈式數據結構:這基礎上還提供了分佈式的多值映射(Multimap),本地緩存映射(LocalCachedMap),有序集(SortedSet),計分排序集(ScoredSortedSet),字典排序集(LexSortedSet),列隊(Queue),阻塞隊列(Blocking Queue),有界阻塞列隊(Bounded Blocking Queue),雙端隊列(Deque),阻塞雙端列隊(Blocking Deque),阻塞公平列隊(Blocking Fair Queue),延遲列隊(Delayed Queue),布隆過濾器(Bloom Filter),原子整長形(AtomicLong),原子雙精度浮點數(AtomicDouble),BitSet 等 Redis 原本沒有的分佈式數據結構。
-
分佈式鎖:Redisson 還實現了 Redis 文檔中提到像分佈式鎖
Lock
這樣的更高階應用場景。事實上 Redisson 並沒有不止步於此,在分佈式鎖的基礎上還提供了聯鎖(MultiLock)
,讀寫鎖(ReadWriteLock)
,公平鎖(Fair Lock)
,紅鎖(RedLock)
,信號量(Semaphore)
,可過期性信號量(PermitExpirableSemaphore)
和閉鎖(CountDownLatch)
這些實際當中對多線程高併發應用至關重要的基本部件。正是通過實現基於 Redis 的高階應用方案,使 Redisson 成爲構建分佈式系統的重要工具。 -
節點:Redisson 作爲獨立節點可以用於獨立執行其他節點發布到
分佈式執行服務
和分佈式調度服務
裏的遠程任務。
二、整合 Redisson
Spring Boot 整合 Redisson 有兩種方案:
-
程序化配置。
-
文件方式配置。
本篇介紹如何用程序化的方式整合 Redisson。
2.1 引入 Maven 依賴
在 passjava-question 微服務的 pom.xml 引入 redisson 的 maven 依賴。
<!-- https://mvnrepository.com/artifact/org.redisson/redisson -->
<dependency>
<groupId>org.redisson</groupId>
<artifactId>redisson</artifactId>
<version>3.15.5</version>
</dependency>
2.2 自定義配置類
下面的代碼是單節點 Redis 的配置。
@Configuration
public class MyRedissonConfig {
/**
* 對 Redisson 的使用都是通過 RedissonClient 對象
* @return
* @throws IOException
*/
@Bean(destroyMethod="shutdown") // 服務停止後調用 shutdown 方法。
public RedissonClient redisson() throws IOException {
// 1.創建配置
Config config = new Config();
// 集羣模式
// config.useClusterServers().addNodeAddress("127.0.0.1:7004", "127.0.0.1:7001");
// 2.根據 Config 創建出 RedissonClient 示例。
config.useSingleServer().setAddress("redis://127.0.0.1:6379");
return Redisson.create(config);
}
}
2.3 測試配置類
新建一個單元測試方法。
@Autowired
RedissonClient redissonClient;
@Test
public void TestRedisson() {
System.out.println(redissonClient);
}
我們運行這個測試方法,打印出 redissonClient
org.redisson.Redisson@77f66138
三、分佈式可重入鎖
3.1 可重入鎖測試
基於 Redis 的 Redisson 分佈式可重入鎖RLock
Java 對象實現了java.util.concurrent.locks.Lock
接口。同時還提供了異步(Async)、反射式(Reactive)和 RxJava2 標準的接口。
RLock lock = redisson.getLock("anyLock");
// 最常見的使用方法
lock.lock();
我們用 passjava 這個開源項目測試下可重入鎖的兩個點:
-
(1)多個線程搶佔鎖,後面鎖需要等待嗎?
-
(2)如果搶佔到鎖的線程所在的服務停了,鎖會不會被釋放?
3.1.1 驗證一:可重入鎖是阻塞的嗎?
@ResponseBody
@GetMapping("test-lock")
public String TestLock() {
// 1.獲取鎖,只要鎖的名字一樣,獲取到的鎖就是同一把鎖。
RLock lock = redisson.getLock("WuKong-lock");
// 2.加鎖
lock.lock();
try {
System.out.println("加鎖成功,執行後續代碼。線程 ID:" + Thread.currentThread().getId());
Thread.sleep(10000);
} catch (Exception e) {
//TODO
} finally {
lock.unlock();
// 3.解鎖
System.out.println("Finally,釋放鎖成功。線程 ID:" + Thread.currentThread().getId());
}
return "test lock ok";
}
http://localhost:11000/question/v1/redisson/test/test-lock
第一個線程釋放鎖之後,第二個線程獲取到了鎖,10 秒後,釋放鎖。
畫了一個流程圖,幫助大家理解。如下圖所示:
-
第一步:線程 A 在 0 秒時,搶佔到鎖,0.1 秒後,開始執行等待 10 s。
-
第二步:線程 B 在 0.1 秒嘗試搶佔鎖,未能搶到鎖(被 A 搶佔了)。
-
第三步:線程 A 在 10.1 秒後,釋放鎖。
-
第四步:線程 B 在 10.1 秒後搶佔到鎖,然後等待 10 秒後釋放鎖。
由此可以得出結論,Redisson 的可重入鎖(lock)是阻塞其他線程的,需要等待其他線程釋放的。
3.1.2 驗證二:服務停了,鎖會釋放嗎?
如果線程 A 在等待的過程中,服務突然停了,那麼鎖會釋放嗎?如果不釋放的話,就會成爲死鎖,阻塞了其他線程獲取鎖。
我們先來看下線程 A 的獲取鎖後的,Redis 客戶端查詢到的結果,如下圖所示:
WuKong-lock 有值,而且大家可以看到 TTL 在不斷變小,說明 WuKong-lock 是自帶過期時間的。
通過觀察,經過 30 秒後,WuKong-lock 過期消失了。說明 Redisson 在停機後,佔用的鎖會自動釋放。
那這又是什麼原理呢?這裏就要提一個概念了,看門狗
。
3.2 看門狗原理
如果負責儲存這個分佈式鎖的 Redisson 節點宕機以後,而且這個鎖正好處於鎖住的狀態時,這個鎖會出現鎖死的狀態。爲了避免這種情況的發生,Redisson 內部提供了一個監控鎖的看門狗
,它的作用是在 Redisson 實例被關閉前,不斷的延長鎖的有效期。
默認情況下,看門狗的檢查鎖的超時時間是 30 秒鐘,也可以通過修改 Config.lockWatchdogTimeout 來另行指定。
如果我們未制定 lock 的超時時間,就使用 30 秒作爲看門狗的默認時間。只要佔鎖成功,就會啓動一個定時任務
:每隔 10 秒重新給鎖設置過期的時間,過期時間爲 30 秒。
如下圖所示:
看門狗原理圖 - 1
當服務器宕機後,因爲鎖的有效期是 30 秒,所以會在 30 秒內自動解鎖。(30 秒等於宕機之前的鎖佔用時間 + 後續鎖佔用的時間)。
如下圖所示:
看門狗原理圖 - 2
3.3 設置鎖過期時間
我們也可以通過給鎖設置過期時間,讓其自動解鎖。
如下所示,設置鎖 8 秒後自動過期。
lock.lock(8, TimeUnit.SECONDS);
如果業務執行時間超過 8 秒,手動釋放鎖將會報錯,如下圖所示:
所以我們如果設置了鎖的自動過期時間,則執行業務的時間一定要小於鎖的自動過期時間,否則就會報錯。
四、王者方案
上一篇我講解了分佈式鎖的五種方案:Redis 分佈式鎖|從青銅到鑽石的五種演進方案,這一篇主要是講解如何用 Redisson 在 Spring Boot 項目中實現分佈式鎖的方案。
因爲 Redisson 非常強大,實現分佈式鎖的方案非常簡潔,所以稱作王者方案
。
原理圖如下:
代碼如下所示:
// 1.設置分佈式鎖
RLock lock = redisson.getLock("lock");
// 2.佔用鎖
lock.lock();
// 3.執行業務
...
// 4.釋放鎖
lock.unlock();
和之前 Redis 的方案相比,簡潔很多。
下面講解下 Redisson 的其他幾種分佈式鎖,相信大家在以後的項目中也會用到。
五、分佈式讀寫鎖
基於 Redis 的 Redisson 分佈式可重入讀寫鎖RReadWriteLock
Java 對象實現了java.util.concurrent.locks.ReadWriteLock
接口。其中讀鎖和寫鎖都繼承了 RLock
接口。
寫鎖是一個排他鎖(互斥鎖),讀鎖是一個共享鎖。
-
讀鎖 + 讀鎖:相當於沒加鎖,可以併發讀。
-
讀鎖 + 寫鎖:寫鎖需要等待讀鎖釋放鎖。
-
寫鎖 + 寫鎖:互斥,需要等待對方的鎖釋放。
-
寫鎖 + 讀鎖:讀鎖需要等待寫鎖釋放。
示例代碼如下:
RReadWriteLock rwlock = redisson.getReadWriteLock("anyRWLock");
// 最常見的使用方法
rwlock.readLock().lock();
// 或
rwlock.writeLock().lock();
另外 Redisson 還通過加鎖的方法提供了leaseTime
的參數來指定加鎖的時間。超過這個時間後鎖便自動解開了。
// 10秒鐘以後自動解鎖
// 無需調用unlock方法手動解鎖
rwlock.readLock().lock(10, TimeUnit.SECONDS);
// 或
rwlock.writeLock().lock(10, TimeUnit.SECONDS);
// 嘗試加鎖,最多等待100秒,上鎖以後10秒自動解鎖
boolean res = rwlock.readLock().tryLock(100, 10, TimeUnit.SECONDS);
// 或
boolean res = rwlock.writeLock().tryLock(100, 10, TimeUnit.SECONDS);
...
lock.unlock();
六、分佈式信號量
基於 Redis 的 Redisson 的分佈式信號量(Semaphore)Java 對象RSemaphore
採用了與java.util.concurrent.Semaphore
相似的接口和用法。同時還提供了異步(Async)、反射式(Reactive)和 RxJava2 標準的接口。
關於信號量的使用大家可以想象一下這個場景,有三個停車位,當三個停車位滿了後,其他車就不停了。可以把車位比作信號,現在有三個信號,停一次車,用掉一個信號,車離開就是釋放一個信號。
我們用 Redisson 來演示上述停車位的場景。
先定義一個佔用停車位的方法:
/**
* 停車,佔用停車位
* 總共 3 個車位
*/
@ResponseBody
@RequestMapping("park")
public String park() throws InterruptedException {
// 獲取信號量(停車場)
RSemaphore park = redisson.getSemaphore("park");
// 獲取一個信號(停車位)
park.acquire();
return "OK";
}
再定義一個離開車位的方法:
/**
* 釋放車位
* 總共 3 個車位
*/
@ResponseBody
@RequestMapping("leave")
public String leave() throws InterruptedException {
// 獲取信號量(停車場)
RSemaphore park = redisson.getSemaphore("park");
// 釋放一個信號(停車位)
park.release();
return "OK";
}
爲了簡便,我用 Redis 客戶端添加了一個 key:“park”,值等於 3,代表信號量爲 park,總共有三個值。
然後用 postman 發送 park 請求佔用一個停車位。
然後在 redis 客戶端查看 park 的值,發現已經改爲 2 了。繼續調用兩次,發現 park 的等於 0,當調用第四次的時候,會發現請求一直處於等待中
,說明車位不夠了。如果想要不阻塞,可以用 tryAcquire 或 tryAcquireAsync。
我們再調用離開車位的方法,park 的值變爲了 1,代表車位剩餘 1 個。
注意:多次執行釋放信號量操作,剩餘信號量會一直增加,而不是到 3 後就封頂了。
其他分佈式鎖:
-
公平鎖(Fair Lock)
-
聯鎖(MultiLock)
-
紅鎖(RedLock)
-
讀寫鎖(ReadWriteLock)
-
可過期性信號量(PermitExpirableSemaphore)
-
閉鎖(CountDownLatch)
還有其他分佈式鎖就不在本篇展開了,感興趣的同學可以查看官方文檔。
緩存系列文章彙總:
緩存實戰(一):20 圖 |6 千字|緩存實戰
緩存實戰(二):Redis 分佈式鎖|從青銅到鑽石的五種演進方案
參考資料:
https://github.com/redisson/redisson
我是悟空,努力變強,變身超級賽亞人!
本文由 Readfog 進行 AMP 轉碼,版權歸原作者所有。
來源:https://mp.weixin.qq.com/s/CbnPRfvq4m1sqo2uKI6qQw