Detaillierte Erläuterung des von Redisson implementierten Prinzips der verteilten Sperre
- 黄舟Original
- 2017-03-07 10:26:382797Durchsuche
In diesem Artikel wird das von Redisson implementierte Prinzip der verteilten Sperre ausführlich vorgestellt. Es hat einen sehr guten Referenzwert. Schauen wir uns den Editor unten an Grundlegende verteilte Redis-Sperre. Ich implementieren die Sperre basierend auf RLock, das von der Redisson-Komponente bereitgestellt wird. In diesem Artikel wird erläutert, wie Redisson die Sperre implementiert.
Die Mechanismen zum Implementieren von Sperren sind in verschiedenen Versionen unterschiedlich
Die kürzlich veröffentlichte Version 3.2.3 von Redisson zitierte, verschiedene Versionen können Sperren implementieren Der Mechanismus ist anders. Die frühere Version schien einfache setnx-, getset- und andere herkömmliche Befehle zu verwenden, um die Konfiguration abzuschließen. In der späteren Zeit wurde das Implementierungsprinzip geändert, da Redis das Skript Lua unterstützte.
setnx muss mit getset und Transaktionen vervollständigt werden, um Deadlock-Probleme besser zu vermeiden, und die neue Version kann dies vermeiden, da sie Lua unterstützt Durch die Verwendung von Transaktionen und die Ausführung mehrerer Redis-Befehle durch Skripte ist der semantische Ausdruck klarer.<dependency> <groupId>org.redisson</groupId> <artifactId>redisson</artifactId> <version>3.2.3</version> </dependency>
Funktionen der RLock-Schnittstelle
Erbt die Standardschnittstelle Lock
Es verfügt über alle Funktionen der Standard-Sperrschnittstelle, wie z. B. Sperren, Entsperren, Trylock usw. Erweitert die Standardschnittstelle Sperre
erweitert viele Methoden: erzwungene Sperrfreigabe, Sperre mit Gültigkeitsdauer und a Satz 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. Wiedereintrittsmechanismus
Es gibt Unterschiede in der Implementierung jeder Version. Der Hauptaspekt bei der Wiedereintrittsmöglichkeit ist die Leistung Geben Sie die Sperre frei. Wenn Sie eine Sperrressource erneut beantragen, müssen Sie den Antragsprozess nicht durchlaufen. Sie müssen nur die erworbene Sperre zurückgeben und die Anzahl der erneuten Einträge aufzeichnen, ä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 des aktuellen Threads eine GUID der RedissonLock-Instanz hinzuzufügen und
über getLockName
Zwei Szenarien für RLock, um die Sperre zu erhalten
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;
}Hier ist der Quellcode von tryLock: tryAcquire-Methode Es soll die Sperre beantragen und die verbleibende Zeit des Sperrgültigkeitszeitraums zurückgeben. Wenn es leer ist, bedeutet dies, dass die Sperre nicht direkt von anderen Threads erworben und zurückgegeben wurde Wartewettbewerbslogik wird eingegeben.
Keine Konkurrenz, erwerben Sie das Schloss direkt
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 {
//有竞争的后续看
}
}Schauen Sie sich die Anschaffung an 1. Was macht Redis hinter der Sperre und Freigabe? Sie können den Redis-Monitor verwenden, um die Ausführung von Redis im Hintergrund zu überwachen. Wenn wir der Methode @RequestLockable hinzufügen, rufen wir tatsächlich Sperren und Entsperren auf. Die folgenden Redis-Befehle sind: Lock
Aufgrund der hoch Die Version von Redis unterstützt Lua-Skripte, daher unterstützt Redisson es auch und übernimmt den Skriptmodus. Wenn Sie mit Lua-Skripten nicht vertraut sind, können Sie es nachschlagen. Die Logik zum Ausführen des Lua-Befehls lautet wie folgt:
Der Sperrvorgang:
<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)});
}
Stellen Sie fest, ob der Sperrschlüssel vorhanden ist. Rufen Sie hset direkt auf, um die aktuellen Thread-Informationen zu speichern, und legen Sie die Ablaufzeit fest. Geben Sie Null zurück, um den Client anzuweisen, die Sperre direkt zu erhalten.
Stellen Sie fest, ob der Sperrschlüssel vorhanden ist. Erhöhen Sie die Anzahl der erneuten Eingaben um 1, setzen Sie die Ablaufzeit zurück und geben Sie Null zurück, um den Client anzuweisen, die Sperre direkt zu erhalten.- wurde von anderen Threads gesperrt, gibt die verbleibende Zeit des Sperrgültigkeitszeitraums zurück und teilt dem Client mit, dass er warten muss.
- Das obige Lua-Skript wird in einen echten Redis-Befehl umgewandelt und der folgende wird tatsächlich nach dem Lua ausgeführt Skriptoperation Redis-Befehl.
"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"
Entsperren
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"
EntsperrvorgangEs scheint komplizierter zu sein:
Wenn der Sperrschlüssel nicht vorhanden ist, senden Sie eine Nachricht, dass das Schloss verfügbar ist
Wenn die Sperre nicht gesperrt ist. Wenn der aktuelle Thread gesperrt ist, wird Null zurückgegeben. Wenn die berechnete Anzahl von Wiedereintritten >0 ist, wird die Ablaufzeit zurückgesetzt.- Wenn die berechnete Anzahl von reentrys ist <=0, dann wird eine Nachricht gesendet, die besagt, dass die Sperre verfügbar ist
- Entsperren Sie den Redis-Befehl ohne Wettbewerb:
Sendet hauptsächlich eine Entsperrnachricht, um die Warteschlange zu wecken. Der Thread konkurriert erneut um die Sperre.
有竞争，等待
有竞争的情况在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，如果只是简单的使用锁也可以自己去实现。
以上就是redisson实现分布式锁原理详解的内容，更多相关内容请关注PHP中文网（www.php.cn）！