Redisson-verteilte Sperre
Die vorherige annotationsbasierte Sperre verfügt über eine Die Art der Sperre ist eine grundlegende verteilte Redis-Sperre. Ich implementieren die Sperre basierend auf dem von der Redisson-Komponente bereitgestellten RLock.
Verschiedene Versionen haben unterschiedliche Sperrmechanismen
zitierte die kürzlich veröffentlichte Version 3.2.3 von Redisson. Frühere Versionen scheinen einfache Setnx-, Getset- und andere herkömmliche Befehle zu verwenden, die jedoch später abgeschlossen werden Das Implementierungsprinzip wurde geändert, da Redis das Skript Lua unterstützt.
<dependency> <groupId>org.redisson</groupId> <artifactId>redisson</artifactId> <version>3.2.3</version></dependency>
setnx muss mit getset und Transaktionen vervollständigt werden, um Deadlock-Probleme besser zu vermeiden, und seitdem Die neue Version unterstützt Lua-Skripte, kann die Verwendung von Transaktionen und die Ausführung mehrerer Redis-Befehle vermeiden und der semantische Ausdruck ist klarer.
Funktionen der RLock-Schnittstelle
Erbt die Standardschnittstellensperre
Verfügt über eine Standardsperre Schnittstelle Alle Funktionen wie Sperren, Entsperren, Trylock usw.
Erweiterte Standardschnittstellensperre
erweitert viele Methoden. Die am häufigsten verwendeten sind: erzwungene Freigabe der Sperre, Sperre mit Gültigkeitsdauer und eine Reihe asynchroner Methoden. Die ersten beiden Methoden dienen hauptsächlich der Lösung des Deadlock-Problems, das durch Standardsperren verursacht werden kann. Nachdem ein Thread beispielsweise eine Sperre erhalten hat, stürzt der Computer ab, auf dem sich der Thread befindet. Zu diesem Zeitpunkt kann der Thread, der die Sperre erworben hat, die Sperre nicht normal aufheben, was dazu führt, dass die verbleibenden Threads, die auf die Sperre warten, warten.
Reentrant Mechanism
Die Implementierung jeder Version ist unterschiedlich. Wenn derselbe Thread erneut Sperrressourcen anwendet, muss er nicht den Anwendungsprozess durchlaufen um weiterhin die erworbene Sperre zurückzugeben und einfach die Anzahl der Wiedereintritte aufzuzeichnen, ähnlich der ReentrantLock-Funktion in JDK. Die Anzahl der Wiedereintritte wird in Verbindung mit dem Befehl hincrby verwendet. Die detaillierten Parameter finden Sie im folgenden Code.
Wie kann ich feststellen, ob es sich um denselben Thread handelt?
redissons Lösung besteht darin, der ID der aktuellen Instanz eine GUID der RedissonLock-Instanz hinzuzufügen Thread, Return von getLockName
public class RedissonLock extends RedissonExpirable implements RLock { final UUID id; protected RedissonLock(CommandExecutor commandExecutor, String name, UUID id) { super(commandExecutor, name); this.internalLockLeaseTime = TimeUnit.SECONDS.toMillis(30L); this.commandExecutor = commandExecutor; this.id = id; } String getLockName(long threadId) { return this.id + ":" + threadId; }
RLock erhält die Szenario mit zwei Sperrnamen
Hier ist der Quellcode von tryLock: Die tryAcquire-Methode soll für die Sperre und Rückgabe gelten Wenn die verbleibende Zeit der Sperrgültigkeitsdauer leer ist, bedeutet dies, dass die Sperre nicht direkt von anderen Threads erworben und zurückgegeben wurde. Wenn die Zeit abgerufen wird, wird die Wartewettbewerbslogik eingegeben.
public boolean tryLock(long waitTime, long leaseTime, TimeUnit unit) throws InterruptedException { long time = unit.toMillis(waitTime); long current = System.currentTimeMillis(); final long threadId = Thread.currentThread().getId(); Long ttl = this.tryAcquire(leaseTime, unit); if(ttl == null) { //直接获取到锁 return true; } else { //有竞争的后续看 } }
Keine Konkurrenz, holen Sie sich das Schloss direkt
Schauen wir uns zunächst an, was Redis hinter dem Erwerb der Sperre und der Freigabe der Sperre macht. Sie können den Redis-Monitor verwenden, um die Ausführung von Redis zu überwachen der Hintergrund. Wenn wir der Methode @RequestLockable hinzufügen, rufen wir tatsächlich Sperren und Entsperren auf. Die folgenden Redis-Befehle sind:
Add Sperren
Da höhere Versionen von Redis Lua-Skripte unterstützen, unterstützt Redisson es auch und übernimmt den Skriptmodus, diejenigen, die dies nicht tun Wer mit Lua-Skripten vertraut ist, kann nachschlagen. Die Logik zum Ausführen des Lua-Befehls lautet wie folgt:
<T> RFuture<T> tryLockInnerAsync(long leaseTime, TimeUnit unit, long threadId, RedisStrictCommand<T> command) { this.internalLockLeaseTime = unit.toMillis(leaseTime); return this.commandExecutor.evalWriteAsync(this.getName(), LongCodec.INSTANCE, command, "if (redis.call(/'exists/', KEYS[1]) == 0) then redis.call(/'hset/', KEYS[1], ARGV[2], 1); redis.call(/'pexpire/', KEYS[1], ARGV[1]); return nil; end; if (redis.call(/'hexists/', KEYS[1], ARGV[2]) == 1) then redis.call(/'hincrby/', KEYS[1], ARGV[2], 1); redis.call(/'pexpire/', KEYS[1], ARGV[1]); return nil; end; return redis.call(/'pttl/', KEYS[1]);", Collections.singletonList(this.getName()), new Object[]{Long.valueOf(this.internalLockLeaseTime), this.getLockName(threadId)}); }
加锁的流程:
判断lock键是否存在,不存在直接调用hset存储当前线程信息并且设置过期时间,返回nil,告诉客户端直接获取到锁。
判断lock键是否存在,存在则将重入次数加1,并重新设置过期时间,返回nil,告诉客户端直接获取到锁。
被其它线程已经锁定,返回锁有效期的剩余时间,告诉客户端需要等待。
"EVAL" "if (redis.call('exists', KEYS[1]) == 0) then redis.call('hset', KEYS[1], ARGV[2], 1); redis.call('pexpire', KEYS[1], ARGV[1]); return nil; end;if (redis.call('hexists', KEYS[1], ARGV[2]) == 1) then redis.call('hincrby', KEYS[1], ARGV[2], 1); redis.call('pexpire', KEYS[1], ARGV[1]); return nil; end;return redis.call('pttl', KEYS[1]);" "1" "lock.com.csp.product.api.service.ProductAppService.searchProductByPage#0" "1000" "346e1eb8-5bfd-4d49-9870-042df402f248:21"
上面的lua脚本会转换成真正的redis命令,下面的是经过lua脚本运算之后实际执行的redis命令。
1486642677.053488 [0 lua] "exists" "lock.com.csp.product.api.service.ProductAppService.searchProductByPage#0"1486642677.053515 [0 lua] "hset" "lock.com.csp.product.api.service.ProductAppService.searchProductByPage#0" "346e1eb8-5bfd-4d49-9870-042df402f248:21" "1"1486642677.053540 [0 lua] "pexpire" "lock.com.csp.product.api.service.ProductAppService.searchProductByPage#0" "1000"
解锁
解锁的流程看起来复杂些:
如果lock键不存在,发消息说锁已经可用
如果锁不是被当前线程锁定,则返回nil
由于支持可重入,在解锁时将重入次数需要减1
如果计算后的重入次数>0,则重新设置过期时间
如果计算后的重入次数<=0,则发消息说锁已经可用
"EVAL" "if (redis.call('exists', KEYS[1]) == 0) then redis.call('publish', KEYS[2], ARGV[1]); return 1; end;if (redis.call('hexists', KEYS[1], ARGV[3]) == 0) then return nil;end; local counter = redis.call('hincrby', KEYS[1], ARGV[3], -1); if (counter > 0) then redis.call('pexpire', KEYS[1], ARGV[2]); return 0; else redis.call('del', KEYS[1]); redis.call('publish', KEYS[2], ARGV[1]); return 1; end; return nil;""2" "lock.com.csp.product.api.service.ProductAppService.searchProductByPage#0" "redisson_lock__channel:{lock.com.csp.product.api.service.ProductAppService.searchProductByPage#0}" "0" "1000" "346e1eb8-5bfd-4d49-9870-042df402f248:21"
无竞争情况下解锁redis命令:
主要是发送一个解锁的消息,以此唤醒等待队列中的线程重新竞争锁。
1486642678.493691 [0 lua] "exists" "lock.com.csp.product.api.service.ProductAppService.searchProductByPage#0"1486642678.493712 [0 lua] "publish" "redisson_lock__channel:{lock.com.csp.product.api.service.ProductAppService.searchProductByPage#0}" "0"
有竞争,等待
有竞争的情况在redis端的lua脚本是相同的,只是不同的条件执行不同的redis命令,复杂的在redisson的源码上。当通过tryAcquire发现锁被其它线程申请时,需要进入等待竞争逻辑中。
this.await返回false,说明等待时间已经超出获取锁最大等待时间,取消订阅并返回获取锁失败
this.await返回true,进入循环尝试获取锁。
public boolean tryLock(long waitTime, long leaseTime, TimeUnit unit) throws InterruptedException { long time = unit.toMillis(waitTime); long current = System.currentTimeMillis(); final long threadId = Thread.currentThread().getId(); Long ttl = this.tryAcquire(leaseTime, unit); if(ttl == null) { return true; } else { //重点是这段 time -= System.currentTimeMillis() - current; if(time <= 0L) { return false; } else { current = System.currentTimeMillis(); final RFuture subscribeFuture = this.subscribe(threadId); if(!this.await(subscribeFuture, time, TimeUnit.MILLISECONDS)) { if(!subscribeFuture.cancel(false)) { subscribeFuture.addListener(new FutureListener() { public void operationComplete(Future<RedissonLockEntry> future) throws Exception { if(subscribeFuture.isSuccess()) { RedissonLock.this.unsubscribe(subscribeFuture, threadId); } } }); } return false; } else { boolean var16; try { time -= System.currentTimeMillis() - current; if(time <= 0L) { boolean currentTime1 = false; return currentTime1; } do { long currentTime = System.currentTimeMillis(); ttl = this.tryAcquire(leaseTime, unit); if(ttl == null) { var16 = true; return var16; } time -= System.currentTimeMillis() - currentTime; if(time <= 0L) { var16 = false; return var16; } currentTime = System.currentTimeMillis(); if(ttl.longValue() >= 0L && ttl.longValue() < time) { this.getEntry(threadId).getLatch().tryAcquire(ttl.longValue(), TimeUnit.MILLISECONDS); } else { this.getEntry(threadId).getLatch().tryAcquire(time, TimeUnit.MILLISECONDS); } time -= System.currentTimeMillis() - currentTime; } while(time > 0L); var16 = false; } finally { this.unsubscribe(subscribeFuture, threadId); } return var16; } } } }
循环尝试一般有如下几种方法:
while循环,一次接着一次的尝试,这个方法的缺点是会造成大量无效的锁申请。
Thread.sleep,在上面的while方案中增加睡眠时间以降低锁申请次数,缺点是这个睡眠的时间设置比较难控制。
基于信息量,当锁被其它资源占用时,当前线程订阅锁的释放事件,一旦锁释放会发消息通知待等待的锁进行竞争,有效的解决了无效的锁申请情况。核心逻辑是this.getEntry(threadId).getLatch().tryAcquire,this.getEntry(threadId).getLatch()返回的是一个信号量,有兴趣可以再研究研究。
redisson依赖
由于redisson不光是针对锁,提供了很多客户端操作redis的方法,所以会依赖一些其它的框架,比如netty,如果只是简单的使用锁也可以自己去实现。
Das obige ist der detaillierte Inhalt vonDetaillierte Erläuterung des Prinzips der von Redisson implementierten verteilten Sperrmethode. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!