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.
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
Verteilte Sperre: Redisson implementiert auch verteilte Sperren, die im Redis-Dokument erwähnt werden Lock
Solche 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作为独立节点可以用于独立执行其他节点发布到分布式执行服务
和分布式调度服务
Distribution Style Execution Service
und Remote-Aufgaben im verteilten Planungsdienst
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>
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); } }
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
Redisson verteilte Wiedereintrittssperre basierend auf RedisRLock
Java-Objekt implementiertjava .util.concurrent.locks.Lock
Schnittstelle. Es bietet außerdem asynchrone (Async), reflektierende (Reactive) und RxJava2-Standardschnittstellen. RLock
Java 对象实现了java.util.concurrent.locks.Lock
接口。同时还提供了异步(Async)、反射式(Reactive)和RxJava2标准的接口。
RLock lock = redisson.getLock("anyLock"); // 最常见的使用方法 lock.lock();
我们用 passjava 这个开源项目测试下可重入锁的两个点:
为了验证以上两点,我写了个 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:
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 秒后,释放锁。
画了一个流程图,帮助大家理解。如下图所示:
由此可以得出结论,Redisson 的可重入锁(lock)是阻塞其他线程的,需要等待其他线程释放的。
如果线程 A 在等待的过程中,服务突然停了,那么锁会释放吗?如果不释放的话,就会成为死锁,阻塞了其他线程获取锁。
我们先来看下线程 A 的获取锁后的,Redis 客户端查询到的结果,如下图所示:
WuKong-lock 有值,而且大家可以看到 TTL 在不断变小,说明 WuKong-lock 是自带过期时间的。
通过观察,经过 30 秒后,WuKong-lock 过期消失了。说明 Redisson 在停机后,占用的锁会自动释放。
那这又是什么原理呢?这里就要提一个概念了,看门狗
。
如果负责储存这个分布式锁的 Redisson 节点宕机以后,而且这个锁正好处于锁住的状态时,这个锁会出现锁死的状态。为了避免这种情况的发生,Redisson内部提供了一个监控锁的看门狗
,它的作用是在Redisson实例被关闭前,不断的延长锁的有效期。
默认情况下,看门狗的检查锁的超时时间是30秒钟,也可以通过修改Config.lockWatchdogTimeout来另行指定。
如果我们未制定 lock 的超时时间,就使用 30 秒作为看门狗的默认时间。只要占锁成功,就会启动一个定时任务
:每隔 10 秒重新给锁设置过期的时间,过期时间为 30 秒。
如下图所示:
当服务器宕机后,因为锁的有效期是 30 秒,所以会在 30 秒内自动解锁。(30秒等于宕机之前的锁占用时间+后续锁占用的时间)。
如下图所示:
我们也可以通过给锁设置过期时间,让其自动解锁。
如下所示,设置锁 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!