Detaillierte Erläuterung des von Redisson implementierten Prinzips der verteilten Sperre

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.

<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

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

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 {
   //有竞争的后续看
  }
 }

Lock

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(\&#39;exists\&#39;, KEYS[1]) == 0) then redis.call(\&#39;hset\&#39;, KEYS[1], ARGV[2], 1); 
    redis.call(\&#39;pexpire\&#39;, KEYS[1], ARGV[1]); return nil; end; 
    if (redis.call(\&#39;hexists\&#39;, KEYS[1], ARGV[2]) == 1) then redis.call(\&#39;hincrby\&#39;, KEYS[1], ARGV[2], 1); 
    redis.call(\&#39;pexpire\&#39;, KEYS[1], ARGV[1]); return nil; end; 
    return redis.call(\&#39;pttl\&#39;, 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.

1. 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

1. 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:

4. 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;
        }
      }
    }
  }

Nach dem Login kopieren

循环尝试一般有如下几种方法：

• while循环，一次接着一次的尝试，这个方法的缺点是会造成大量无效的锁申请。

• Thread.sleep，在上面的while方案中增加睡眠时间以降低锁申请次数，缺点是这个睡眠的时间设置比较难控制。

• 基于信息量，当锁被其它资源占用时，当前线程订阅锁的释放事件，一旦锁释放会发消息通知待等待的锁进行竞争，有效的解决了无效的锁申请情况。核心逻辑是this.getEntry(threadId).getLatch().tryAcquire，this.getEntry(threadId).getLatch()返回的是一个信号量，有兴趣可以再研究研究。

redisson依赖

由于redisson不光是针对锁，提供了很多客户端操作redis的方法，所以会依赖一些其它的框架，比如netty，如果只是简单的使用锁也可以自己去实现。

 以上就是redisson实现分布式锁原理详解的内容，更多相关内容请关注PHP中文网（m.sbmmt.com）！