Die Königslösung unter den verteilten Schlössern – Redisson

Es gibt im Internet verschiedene Lösungen für die Implementierung verteilter Sperren in Redis, aber was ist die Königslösung?

Die Antwort lautet: Redisson.

Werfen wir zunächst einen Blick darauf, was die offizielle Website von Redis über verteilte Sperren sagt:

Und die Java-Version des verteilten Sperrrahmens ist Redisson.

Dieser praktische Inhalt basiert auf meinem Open-Source-Projekt PassJava zur Integration von Redisson.

Ich habe 后端、前端、小程序都上传到同一个仓库里面了，大家可以通过 Github 或 码云besuch gesetzt. Die Adresse lautet wie folgt:

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

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

Supporting Tutorial: www.passjava.cn

Vor dem eigentlichen Kampf werfen wir zunächst einen Blick auf die Prinzipien der Verwendung von Redisson.

1. Was ist Redisson?

Wenn Sie Redis bereits verwendet haben, erzielen Sie mit Redisson das doppelte Ergebnis mit halbem Aufwand. Redisson bietet die einfachste und bequemste Möglichkeit, Redis zu verwenden.

Der Zweck von Redisson besteht darin, die Trennung der Benutzer bezüglich Redis zu fördern, damit sich Benutzer mehr auf die Verarbeitung der Geschäftslogik konzentrieren können.

Redisson ist ein Java In-Memory Data Grid, das auf Basis von Redis implementiert wird.

• Netty-Framework: Redisson übernimmt das NIO-basierte Netty-Framework, das nicht nur als Redis-basierter Treiber-Client dienen kann, sondern auch Verbindungsfunktionen für verschiedene Konfigurationen von Redis bereitstellt und Redis-Befehle synchronisieren kann . Die Funktion des Sendens, asynchrones Senden, asynchrones Stream-Senden oder Pipeline-Senden, LUA-Skriptausführungsverarbeitung und die Funktion der Verarbeitung der zurückgegebenen Ergebnisse

  ? (LocalCachedMap), geordneter Satz (SortedSet), bewerteter sortierter Satz (ScoredSortedSet), wörterbuchsortierter Satz (LexSortedSet), Warteschlange (Queue), blockierende Warteschlange (Blocking Queue), begrenzte blockierende Warteschlange (Bounded Blocking Queue), doppelte Deque, blockierende Deque , Blocking Fair Queue, Delayed Queue, Bloom Filter, AtomicLong, Atomic Double Precision Gleitkommazahlen (AtomicDouble), BitSet und andere verteilte Datenstrukturen, die Redis ursprünglich nicht hat.

Verteilte Sperre: Redisson implementiert auch verteilte Sperren, die im Redis-Dokument erwähnt werden LockSolche fortgeschritteneren Anwendungsszenarien. Tatsächlich hört Redisson hier nicht auf und bietet auch MultiLock ), ReadWriteLock (ReadWriteLock), Fair Lock, RedLock, Semaphore, Expirable Semaphore (PermitExpirableSemaphore) und Latch (CountDownLatch) Dies sind grundlegende Komponenten, die für Multithread-Anwendungen mit hoher Parallelität von entscheidender Bedeutung sind. Durch die Implementierung hochwertiger Anwendungslösungen auf Basis von Redis wird Redisson zu einem wichtigen Werkzeug für den Aufbau verteilter Systeme. Lock这样的更高阶应用场景。事实上Redisson并没有不止步于此，在分布式锁的基础上还提供了联锁（MultiLock），读写锁（ReadWriteLock），公平锁（Fair Lock），红锁（RedLock），信号量（Semaphore），可过期性信号量（PermitExpirableSemaphore）和闭锁（CountDownLatch）这些实际当中对多线程高并发应用至关重要的基本部件。正是通过实现基于Redis的高阶应用方案，使Redisson成为构建分布式系统的重要工具。

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

Knoten: Redisson als unabhängiger Knoten kann verwendet werden, um andere Knoten unabhängig auszuführen, die in Distribution Style Execution Service und Remote-Aufgaben im verteilten Planungsdienst

• 2. Redisson integrieren
• Spring Boot-Integration Redisson bietet zwei Lösungen:

Programmatische Konfiguration.

🎜🎜Konfiguration des Dateimodus. 🎜🎜🎜🎜Dieser Artikel stellt vor, wie man Redisson programmgesteuert integriert. 🎜

2.1 Einführung der Maven-Abhängigkeit

Führen Sie die Maven-Abhängigkeit von Redisson in der pom.xml des Mikrodienstes passjava-question ein.

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

2.2 Benutzerdefinierte Konfigurationsklasse

Der folgende Code ist die Konfiguration von Redis mit einem einzelnen Knoten.

@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 Testkonfigurationsklasse

Erstellen Sie eine neue Unit-Test-Methode.

@Autowired
RedissonClient redissonClient;

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

Wir führen diese Testmethode aus und drucken RedissonClient aus

org.redisson.Redisson@77f66138

3. Verteilte Wiedereintrittssperre

3.1 Wiedereintrittssperrentest

Redisson verteilte Wiedereintrittssperre basierend auf RedisRLockJava-Objekt implementiertjava .util.concurrent.locks.LockSchnittstelle. Es bietet außerdem asynchrone (Async), reflektierende (Reactive) und RxJava2-Standardschnittstellen. 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";
}

Wir verwenden das Open-Source-Projekt passjava, um die beiden Punkte der Wiedereintrittssperre zu testen:

• (1) Wenn mehrere Threads die Sperre ergreifen, müssen sie dann auf nachfolgende Sperren warten?
• (2) Wenn der Dienst, bei dem der Thread, der die Sperre ergriffen hat, angehalten wurde, wird die Sperre dann freigegeben?

3.1.1 Überprüfung 1: Blockieren Wiedereintrittssperren?

Um die beiden oben genannten Punkte zu überprüfen, habe ich ein Demoprogramm geschrieben: Der Codeprozess besteht darin, WuKong -lock sperrt, sperrt dann, gibt die Thread-ID aus, wartet 10 Sekunden, gibt dann die Sperre frei und gibt schließlich die Antwort zurück: „Testsperre ok“.

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

Überprüfen Sie zuerst den ersten Punkt und verwenden Sie zwei http-Anfragen, um die Vorkaufssperre zu testen. 🎜🎜Angeforderte URL: 🎜

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 秒。

如下图所示：

看门狗原理图-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 请求占用一个停车位。

Dann überprüfen Sie den Wert von Park auf dem Redis-Client und stellen Sie fest, dass er auf 2 geändert wurde. Rufen Sie weiterhin zweimal an und stellen Sie fest, dass der Parkwert gleich 0 ist. Beim vierten Anruf werden Sie feststellen, dass die Anforderung bei 等待中 war, was darauf hinweist, dass nicht genügend Parkplätze vorhanden sind. Wenn Sie eine Blockierung vermeiden möchten, können Sie tryAcquire oder tryAcquireAsync verwenden.

Wir rufen dann die Methode zum Verlassen des Parkplatzes auf und der Wert von park ändert sich auf 1, was bedeutet, dass noch 1 Parkplatz übrig ist.

Hinweis: Wenn der Semaphor-Freigabevorgang mehrmals ausgeführt wird, erhöht sich der verbleibende Semaphor weiter, anstatt nach 3 Jahren begrenzt zu werden.

Andere verteilte Schlösser:

• Fair Lock

• MultiLock

• RedLock

• .

  Lesen-Schreiben Sperre ( ReadWriteLock)

• Expirable Semaphore (PermitExpirableSemaphore )

• Latch (CountDownLatch)

und andere verteilte Schlösser werden in diesem Artikel nicht erweitert. Interessierte Studenten können offizielle Dokumente einsehen.

Das obige ist der detaillierte Inhalt vonDie Königslösung unter den verteilten Schlössern – Redisson. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!