La solution reine parmi les serrures distribuées - Redisson

Il existe différentes solutions sur Internet pour implémenter des verrous distribués dans Redis, mais quelle est la solution reine ?

La réponse est : Redisson.

Jetons d'abord un coup d'œil à ce que dit le site officiel de Redis à propos des verrous distribués :

Et la version Java du framework de verrouillage distribué est Redisson.

Ce contenu pratique sera basé sur mon projet open source PassJava pour intégrer Redisson.

Je mets 后端、前端、小程序都上传到同一个仓库里面了，大家可以通过 Github 或 码云visite. L'adresse est la suivante :

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

Code Cloud : https://gitee.com/jayh2018/PassJava-Platform

Supporting Tutoriel : www.passjava.cn

Avant le combat proprement dit, examinons d'abord les principes d'utilisation de Redisson.

1. Qu'est-ce que Redisson ?

Si vous avez déjà utilisé Redis, vous obtiendrez deux fois le résultat avec la moitié de l'effort en utilisant Redisson. Redisson fournit le moyen le plus simple et le plus pratique d'utiliser Redis.

Le but de Redisson est de promouvoir la séparation des préoccupations des utilisateurs (Separation of Concern) à propos de Redis, afin que les utilisateurs puissent se concentrer davantage sur le traitement de la logique métier.

Redisson est une grille de données Java In-Memory implémentée sur la base de Redis.

• Netty framework : Redisson adopte le framework Netty basé sur NIO, qui peut non seulement servir de client pilote sous-jacent Redis, mais également fournir des fonctions de connexion pour diverses configurations de Redis et synchroniser les commandes Redis. . La fonction d'envoi, d'envoi asynchrone, d'envoi de flux asynchrone ou d'envoi de pipeline, de traitement d'exécution de script LUA et de fonction de traitement des résultats renvoyés

  .

• Structure de données de base : Le Redis natif Hash，List，Set，String，Geo，HyperLogLog等数据结构封装为Java里大家最熟悉的映射（Map），列表（List），集（Set），通用对象桶（Object Bucket），地理空间对象桶（Geospatial Bucket），基数估计算法（HyperLogLog） et d'autres structures,

• Structure de données distribuée : Sur cette base, il fournit également un mappage multi-valeurs distribué (Multimap), un cache local Map (LocalCachedMap), ensemble ordonné (SortedSet), ensemble trié par notation (ScoredSortedSet), ensemble trié par dictionnaire (LexSortedSet), file d'attente (Queue), file d'attente de blocage (Blocking Queue), file d'attente de blocage limitée (Bounded Blocking Queue), double Deque, Blocking Deque , blocage de la file d'attente équitable, de la file d'attente retardée, du filtre Bloom, d'AtomicLong, des nombres à virgule flottante Atomic Double Precision (AtomicDouble), BitSet et d'autres structures de données distribuées que Redis n'a pas à l'origine.

• Verrouillage distribué : Redisson implémente également les verrous distribués mentionnés dans le document Redis Verrouiller De tels scénarios d'application plus avancés. En fait, Redisson ne s'arrête pas là. Sur la base de verrous distribués, il propose également MultiLock ), ReadWriteLock (ReadWriteLock), Fair Lock, , <code style="font-size: 14px;border-radius: 4px;font-family: " operator mono consolas monaco menlo monospace mot-break: break-all rgb d>Sémaphore, Sémaphore expirable (PermitExpirableSemaphore) et Ce sont des composants de base qui sont cruciaux pour les applications multithread à haute concurrence. C'est grâce à la mise en œuvre de solutions applicatives de haut niveau basées sur Redis que Redisson devient un outil important pour la construction de systèmes distribués. <code style='font-size: 14px;border-radius: 4px;font-family: "Operator Mono", Consolas, Monaco, Menlo, monospace;word-break: break-all;color: rgb(155, 110, 35);background-color: rgb(255, 245, 227);padding: 3px;margin: 3px;'>Lock这样的更高阶应用场景。事实上Redisson并没有不止步于此，在分布式锁的基础上还提供了联锁（MultiLock），读写锁（ReadWriteLock），公平锁（Fair Lock），红锁（RedLock），信号量（Semaphore），可过期性信号量（PermitExpirableSemaphore）和闭锁（CountDownLatch）这些实际当中对多线程高并发应用至关重要的基本部件。正是通过实现基于Redis的高阶应用方案，使Redisson成为构建分布式系统的重要工具。

• 节点：Redisson作为独立节点可以用于独立执行其他节点发布到分布式执行服务和分布式调度服务

Node : Redisson en tant que nœud indépendant peut être utilisé pour exécuter indépendamment d'autres nœuds publiés sur Service d'exécution de style de distribution et Tâches à distance dans le service de planification distribué.

• 2. Intégrer Redisson
• Intégration Spring Boot Redisson propose deux solutions :

2.1 Présentation de la dépendance Maven

Introduisez la dépendance maven de Redisson dans le pom.xml du microservice passjava-question.

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

2.2 Classe de configuration personnalisée

Le code suivant est la configuration de Redis à nœud unique.

@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 Classe de configuration de test

Créez une nouvelle méthode de test unitaire.

@Autowired
RedissonClient redissonClient;

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

Nous exécutons cette méthode de test et imprimons redissonClient

org.redisson.Redisson@77f66138

3. Verrouillage réentrant distribué

3.1 Test de verrouillage réentrant

Verrouillage réentrant distribué Redisson basé sur RedisRLockL'objet Java implémentejava .util.concurrent.locks.Lockinterface. Il fournit également des interfaces standard asynchrones (Async), réfléchissantes (Reactive) et RxJava2. RLockJava 对象实现了java.util.concurrent.locks.Lock接口。同时还提供了异步（Async）、反射式（Reactive）和RxJava2标准的接口。

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

我们用 passjava 这个开源项目测试下可重入锁的两个点：

• （1）多个线程抢占锁，后面锁需要等待吗？
• （2）如果抢占到锁的线程所在的服务停了，锁会不会被释放？

3.1.1 验证一：可重入锁是阻塞的吗？

为了验证以上两点，我写了个 demo 程序：代码的流程就是设置WuKong-lock

@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";
}

• (1) Si plusieurs threads saisissent le verrou, doivent-ils attendre les verrous suivants ?
• (2) Si le service sur lequel le thread qui a saisi le verrou est arrêté, le verrou sera-t-il libéré ?

3.1.1 Vérification 1 : les verrous réentrants bloquent-ils ?

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

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

第一个线程对应的线程 ID 为 86，10秒后，释放锁。在这期间，第二个线程需要等待锁释放。

第一个线程释放锁之后，第二个线程获取到了锁，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 秒。

如下图所示：

当服务器宕机后，因为锁的有效期是 30 秒，所以会在 30 秒内自动解锁。（30秒等于宕机之前的锁占用时间+后续锁占用的时间）。

如下图所示：

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 请求占用一个停车位。

Vérifiez ensuite la valeur de park sur le client Redis et constatez qu'elle a été modifiée en 2. Continuez à appeler deux fois et constatez que le parc est égal à 0. Lors du quatrième appel, vous constaterez que la demande a été à 等待中, indiquant qu'il n'y a pas assez de places de stationnement. Si vous souhaitez éviter le blocage, vous pouvez utiliser tryAcquire ou tryAcquireAsync.

On appelle alors la méthode de sortie de la place de parking, et la valeur de park passe à 1, ce qui signifie qu'il reste 1 place de parking.

Remarque : Si vous exécutez l'opération de libération du sémaphore plusieurs fois, le sémaphore restant continuera d'augmenter au lieu d'être plafonné après 3.

Autres verrous distribués :

• Fair Lock

• MultiLock

• RedLock

• Verrouillage en lecture-écriture ( ReadWriteLock)

• Sémaphore expirable (PermitExpirableSemaphore )

• Lock (CountDownLatch)

et d'autres verrous distribués ne seront pas développés dans cet article, les étudiants intéressés peuvent consulter les documents officiels.