レディソンです。

backend、frontend、小プログラムを同じウェアハウスにアップロードしました。Github または ## を使用できます。 #codeyun にアクセスしてください。アドレスは次のとおりです:

Github

: https://github.com/Jackson0714/PassJava-Platform

Code Cloud

：https://gitee.com/jayh2018/PassJava-Platform

Supporting Tutorial

: www.passjava.cn

実際の戦闘の前に、 「レディソンの原理」の使い方を見てください。

1.レディソンとは何ですか?

以前に Redis を使用したことがある場合は、Redisson を使用すると、半分の労力で 2 倍の結(jié)果が得られます。Redisson は、Redis を使用する最も簡単で便利な方法を提供します。

Redisson の目的は、ユーザー間で Redis の関心の分離 (Separation of Concern) を促進し、ユーザーがビジネス ロジックの処理により集中できるようにすることです。

Redisson は、Redis に基づいて実裝された Java インメモリ データ グリッド (In-Memory Data Grid) です。

• Netty フレームワーク: Redisson は、Redis として機能するだけでなく、NIO ベースの Netty フレームワークを採用しています。基盤となるドライバー client には、Redis のさまざまな構(gòu)成形式への接続を提供する機能、Redis コマンドを同期、非同期、非同期ストリーミングまたはパイプラインで送信する機能、LUA スクリプトの実行処理、および返された結(jié)果を処理する機能があります

• 基本データ構(gòu)造: ネイティブ Redis Hash、List、Set、String、Geo、HyperLogLog およびその他のデータ構(gòu)造は、Java で最もよく知られた マッピング (Map) 、## にカプセル化されます。 #List,Set,General Object Bucket,Geospatial Bucket, カーディナリティ推定アルゴリズム (HyperLogLog) およびその他の構(gòu)造、

• #分散データ構(gòu)造

  : これに基づいて、Multimap、LocalCachedMap、SortedSet、ScoredSortedSet、LexSortedSet、Queue、Blocking Queue、 Bounded Blocking Queue、Deque、Blocking Deque、Blocking Fair Queue、Delayed Queue、Bloom Filter、アトミック整數(shù)(AtomicLong)、アトミック倍精度浮動小數(shù)點數(shù)(AtomicDouble)、BitSetなど、Redisが本來持っていない分散データ構(gòu)造。

• 分散ロック: Redisson は、Redis ドキュメントのアプリケーション シナリオで説明されている分散ロック Lock のような高レベルのロックも実裝します。実際、Redisson はそれだけではなく、分散ロックに基づいて、 Interlock (MultiLock) 、ReadWriteLock (ReadWriteLock) 、Fair Lock (Fair Lock) も提供します。 , Red Lock (RedLock) , セマフォ (Semaphore) , Expirable Semaphore (PermitExpirableSemaphore) および ロック (CountDownLatch) これらマルチスレッドの同時実行性の高いアプリケーションにとって重要な基本コンポーネントです。 Redisson が分散システムを構(gòu)築するための重要なツールとなるのは、Redis に基づく高次アプリケーション ソリューションの実裝を通じてです。

• Node: 獨立ノードとしての Redisson を使用して、分散実行サービス に公開された他のノードを獨立して実行できます。 Distributed Scheduling Service のリモート タスク。

#2. Redisson の統(tǒng)合

• プログラムによる構(gòu)成。
#ファイルモードの設(shè)定。
この記事では、Redisson をプログラムで統(tǒng)合する方法を紹介します。

2.1 Maven 依存関係の導(dǎo)入

passjava-question マイクロサービスの pom.xml に redisson の Maven 依存関係を?qū)毪筏蓼埂?

<!-- https://mvnrepository.com/artifact/org.redisson/redisson -->
<dependency>
    <groupId>org.redisson</groupId>
    <artifactId>redisson</artifactId>
    <version>3.15.5</version>
</dependency>

2.2 カスタム構(gòu)成クラス

次のコードは、単一ノード Redis の構(gòu)成です。

@Configuration
public class MyRedissonConfig {
    /**
     * 對 Redisson 的使用都是通過 RedissonClient 對象
     * @return
     * @throws IOException
     */
    @Bean(destroyMethod="shutdown") // 服務(wù)停止后調(diào)用 shutdown 方法。
    public RedissonClient redisson() throws IOException {
        // 1.創(chuàng)建配置
        Config config = new Config();
        // 集群模式
        // config.useClusterServers().addNodeAddress("127.0.0.1:7004", "127.0.0.1:7001");
        // 2.根據(jù) Config 創(chuàng)建出 RedissonClient 示例。
        config.useSingleServer().setAddress("redis://127.0.0.1:6379");
        return Redisson.create(config);
    }
}

2.3 テスト構(gòu)成クラス

新しい単體テスト メソッドを作成します。

@Autowired
RedissonClient redissonClient;

@Test
public void TestRedisson() {
    System.out.println(redissonClient);
}

このテスト メソッドを?qū)g行し、redissonClientを出力します

org.redisson.Redisson@77f66138

3. 分散リエントラント ロック

3.1 リエントラント ロック テスト

Redis に基づく Redisson 分散リエントラント ロックRLockJava オブジェクトは、java.util.concurrent.locks.Lock インターフェイスを?qū)g裝します。また、非同期 (Async)、反射型 (Reactive)、および RxJava2 標(biāo)準(zhǔn)インターフェイスも提供します。

RLock lock = redisson.getLock("anyLock");
// 最常見的使用方法
lock.lock();

passjava オープン ソース プロジェクトを使用して、2 つの再入可能ロックをテストします:

• (1) 複數(shù)のスレッドがロックを捕捉します。後続のロックは待機する必要がありますか? ?
• (2) ロックをプリエンプトしたスレッドが存在するサービスが停止した場合、ロックは解放されますか?

3.1.1 検証 1: リエントラント ロックはブロックされていますか?

上記 2 點を確認(rèn)するために、デモ プログラムを作成しました。コード プロセスは、WuKong-lock ロックを設(shè)定し、それをロックし、スレッド ID を出力して待機するというものです。 10 秒間ロックを解除すると、最終的に「test lock ok」という応答が返されます。

@ResponseBody
@GetMapping("test-lock")
public String TestLock() {
    // 1.獲取鎖，只要鎖的名字一樣，獲取到的鎖就是同一把鎖。
    RLock lock = redisson.getLock("WuKong-lock");

    // 2.加鎖
    lock.lock();
    try {
        System.out.println("加鎖成功，執(zhí)行后續(xù)代碼。線程 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";
}

まず最初の點を確認(rèn)し、2 つの http リクエストを使用してプリエンプション ロックをテストします。

リクエストされた URL:

http://localhost:11000/question/v1/redisson/test/test-lock

第一個線程對應(yīng)的線程 ID 為 86，10秒后，釋放鎖。在這期間，第二個線程需要等待鎖釋放。

第一個線程釋放鎖之后，第二個線程獲取到了鎖，10 秒后，釋放鎖。

畫了一個流程圖，幫助大家理解。如下圖所示：

• 第一步：線程 A 在 0 秒時，搶占到鎖，0.1 秒后，開始執(zhí)行等待 10 s。
• 第二步：線程 B 在 0.1 秒嘗試搶占鎖，未能搶到鎖（被 A 搶占了）。
• 第三步：線程 A 在 10.1 秒后，釋放鎖。
• 第四步：線程 B 在 10.1 秒后搶占到鎖，然后等待 10 秒后釋放鎖。

由此可以得出結(jié)論，Redisson 的可重入鎖（lock）是阻塞其他線程的，需要等待其他線程釋放的。

3.1.2 驗證二：服務(wù)停了，鎖會釋放嗎？

如果線程 A 在等待的過程中，服務(wù)突然停了，那么鎖會釋放嗎？如果不釋放的話，就會成為死鎖，阻塞了其他線程獲取鎖。

我們先來看下線程 A 的獲取鎖后的，Redis 客戶端查詢到的結(jié)果，如下圖所示：

WuKong-lock 有值，而且大家可以看到 TTL 在不斷變小，說明 WuKong-lock 是自帶過期時間的。

通過觀察，經(jīng)過 30 秒后，WuKong-lock 過期消失了。說明 Redisson 在停機后，占用的鎖會自動釋放。

那這又是什么原理呢？這里就要提一個概念了，看門狗。

3.2 看門狗原理

如果負(fù)責(zé)儲存這個分布式鎖的 Redisson 節(jié)點宕機以后，而且這個鎖正好處于鎖住的狀態(tài)時，這個鎖會出現(xiàn)鎖死的狀態(tài)。為了避免這種情況的發(fā)生，Redisson內(nèi)部提供了一個監(jiān)控鎖的看門狗，它的作用是在Redisson實例被關(guān)閉前，不斷的延長鎖的有效期。

默認(rèn)情況下，看門狗的檢查鎖的超時時間是30秒鐘，也可以通過修改Config.lockWatchdogTimeout來另行指定。

如果我們未制定 lock 的超時時間，就使用 30 秒作為看門狗的默認(rèn)時間。只要占鎖成功，就會啟動一個定時任務(wù)：每隔 10 秒重新給鎖設(shè)置過期的時間，過期時間為 30 秒。

如下圖所示：

當(dāng)服務(wù)器宕機后，因為鎖的有效期是 30 秒，所以會在 30 秒內(nèi)自動解鎖。（30秒等于宕機之前的鎖占用時間+后續(xù)鎖占用的時間）。

如下圖所示：

3.3 設(shè)置鎖過期時間

我們也可以通過給鎖設(shè)置過期時間，讓其自動解鎖。

如下所示，設(shè)置鎖 8 秒后自動過期。

lock.lock(8, TimeUnit.SECONDS);

如果業(yè)務(wù)執(zhí)行時間超過 8 秒，手動釋放鎖將會報錯，如下圖所示：

所以我們?nèi)绻O(shè)置了鎖的自動過期時間，則執(zhí)行業(yè)務(wù)的時間一定要小于鎖的自動過期時間，否則就會報錯。

四、王者方案

上一篇我講解了分布式鎖的五種方案：Redis 分布式鎖｜從青銅到鉆石的五種演進方案，這一篇主要是講解如何用 Redisson 在 Spring Boot 項目中實現(xiàn)分布式鎖的方案。

因為 Redisson 非常強大，實現(xiàn)分布式鎖的方案非常簡潔，所以稱作王者方案。

原理圖如下：

代碼如下所示：

// 1.設(shè)置分布式鎖
RLock lock = redisson.getLock("lock");
// 2.占用鎖
lock.lock();
// 3.執(zhí)行業(yè)務(wù)
...
// 4.釋放鎖
lock.unlock();

和之前 Redis 的方案相比，簡潔很多。

下面講解下 Redisson 的其他幾種分布式鎖，相信大家在以后的項目中也會用到。

五、分布式讀寫鎖

基于 Redis 的 Redisson 分布式可重入讀寫鎖RReadWriteLock Java對象實現(xiàn)了java.util.concurrent.locks.ReadWriteLock接口。其中讀鎖和寫鎖都繼承了 RLock接口。

寫鎖是一個排他鎖（互斥鎖），讀鎖是一個共享鎖。

• 讀鎖 + 讀鎖：相當(dāng)于沒加鎖，可以并發(fā)讀。
• 讀鎖 + 寫鎖：寫鎖需要等待讀鎖釋放鎖。
• 寫鎖 + 寫鎖：互斥，需要等待對方的鎖釋放。
• 寫鎖 + 讀鎖：讀鎖需要等待寫鎖釋放。

示例代碼如下：

RReadWriteLock rwlock = redisson.getReadWriteLock("anyRWLock");
// 最常見的使用方法
rwlock.readLock().lock();
// 或
rwlock.writeLock().lock();

另外Redisson還通過加鎖的方法提供了leaseTime的參數(shù)來指定加鎖的時間。超過這個時間后鎖便自動解開了。

// 10秒鐘以后自動解鎖
// 無需調(diào)用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標(biāo)準(zhǔn)的接口。

關(guān)于信號量的使用大家可以想象一下這個場景，有三個停車位，當(dāng)三個停車位滿了后，其他車就不停了?？梢园衍囄槐茸餍盘?，現(xiàn)在有三個信號，停一次車，用掉一個信號，車離開就是釋放一個信號。

我們用 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 發(fā)送 park 請求占用一個停車位。

次に、redis クライアントで park の値を確認(rèn)すると、2 に変更されていることがわかります。呼び出しを 2 回続けて、park が 0 であることがわかります。4 回目の呼び出しでは、要求が waiting であることがわかり、十分な駐車スペースがないことが示されます。ブロックを回避したい場合は、tryAcquire または tryAcquireAsync を使用できます。

駐車スペースから出るメソッドを再度呼び出します。park の値は 1 に変更されます。これは、駐車スペースが 1 つ殘っていることを意味します。

注: セマフォ解放操作が複數(shù)回実行されると、殘りのセマフォは 3 で制限されるのではなく、増加し続けます。

その他の分散ロック:

• フェア ロック

• インターロック (マルチロック)

• #レッド ロック (RedLock)

• ##読み取り/書き込みロック (ReadWriteLock)

• 期限切れセマフォ (PermitExpirableSemaphore)

• ラッチ (CountDownLatch)

この記事では説明しない分散ロックが他にもあります。興味のある學(xué)生は公式ドキュメントを確認(rèn)してください。