Bringen Sie Ihnen bei, wie Sie SETNX von Redis richtig verwenden, um den Sperrmechanismus zu implementieren

Die folgende Kolumne des Redis-Tutorials wird Ihnen die korrekte Verwendung von Rediss SETNX zur Implementierung des Sperrmechanismus vorstellen. Ich hoffe, dass es Freunden in Not hilfreich sein wird!

setNX ist die Abkürzung für set if not exist, das heißt, es wird nur gesetzt, wenn es nicht existiert. Es gibt 1 zurück, wenn die Einstellung erfolgreich ist, und 0, wenn die Einstellung fehlschlägt. Es kann verwendet werden, um den Sperreffekt zu erzielen, aber viele Menschen haben einige Probleme, die sie bei der Verwendung nicht berücksichtigen.

Zum Beispiel fügt eine bestimmte Schnittstelle zum Abfragen einer Datenbank aufgrund eines großen Anforderungsvolumens einen Cache hinzu und stellt ihn so ein, dass er nach Ablauf des Caches aktualisiert wird. Wenn die Parallelität relativ groß ist und der Cache abläuft, fragt eine große Anzahl gleichzeitiger Anforderungen direkt die Datenbank ab, was zu einer Lawine führt. Das Lawinenproblem kann vermieden werden, wenn ein Sperrmechanismus verwendet wird, um nur eine Anforderung zur Aktualisierung des Caches zu steuern. Das Folgende ist die Sperrmethode, an die viele Menschen unbewusst denken: Rufen Sie die Sperre über setNX ab. Aktualisieren Sie bei Erfolg den Cache und löschen Sie die Sperre. Tatsächlich liegt hier ein ernstes Problem vor: Wenn der Cache aus irgendeinem Grund unerwartet beendet wird, wird die Sperre nicht gelöscht und bleibt immer bestehen, sodass der Cache niemals aktualisiert wird. Um dieses Problem zu lösen, denken einige Leute möglicherweise darüber nach, wie folgt eine Ablaufzeit für die Sperre festzulegen: Exec muss verwendet werden, um die Atomizität der Anfrage sicherzustellen und zu vermeiden, dass setNX erfolgreich war, Expire jedoch fehlschlug. Dabei besteht immer noch ein Problem: Wenn mehrere Anforderungen eintreffen, kann zwar nur das SetNX einer Anforderung erfolgreich sein, das Ablaufen jeder Anforderung kann jedoch erfolgreich sein. Dies bedeutet, dass die Ablaufzeit aktualisiert werden kann, wodurch die Sperre bestehen bleibt gesperrt. Es ist effektiv, löst aber immer noch nicht das oben genannte Problem. Offensichtlich kann setNX diese Anforderungen nicht erfüllen. Ab Redis 2.6.12 umfasst SET auch die Funktion zum Festlegen der Ablaufzeit, sodass die Verwendung von SET die oben genannten Probleme lösen kann Tatsächlich liegt immer noch ein Problem vor. Wenn eine Anforderung zum Aktualisieren des Caches länger als die Gültigkeitsdauer der Sperre dauert und die Sperre während des Cache-Aktualisierungsvorgangs ungültig wird, erhält eine andere Anforderung die Sperre, die vorherige Anforderung jedoch nicht aktualisiert, bis die Cache-Aktualisierung abgeschlossen ist. Wenn Sie die Sperre direkt löschen, kann es vorkommen, dass Sie versehentlich die durch andere Anforderungen erstellte Sperre löschen. Um dieses Problem zu vermeiden, können Sie beim Erstellen der Sperre einen Zufallswert eingeben und diesen beim Löschen der Sperre beurteilen

$rs = $redis->setNX($key, $value);
if ($rs) {
    //处理更新缓存逻辑
    // ......
    //删除锁
    $redis->del($key);
}

Das obige ist der detaillierte Inhalt vonBringen Sie Ihnen bei, wie Sie SETNX von Redis richtig verwenden, um den Sperrmechanismus zu implementieren. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!