Leistungsvergleich verteilter Sperren, die von Redis implementiert wurden

Da der Umfang von Internetanwendungen immer größer wird, werden verteilte Systeme immer häufiger. In diesen Systemen sind verteilte Sperren ein wesentliches Merkmal. Aufgrund der starken Nachfrage nach verteilten Sperren gibt es verschiedene Implementierungsmethoden. Unter diesen ist Redis ein beliebtes Tool, das häufig bei der Implementierung verteilter Sperren verwendet wird. In diesem Artikel untersuchen wir den Leistungsvergleich verteilter Sperren, die von Redis implementiert werden.

1. Grundkonzepte von Redis

Bevor wir die verteilte Sperrleistung von Redis diskutieren, müssen wir einige Grundkonzepte von Redis verstehen.

1. Redis

Redis ist ein leistungsstarkes Schlüsselwertspeichersystem, das häufig in Szenarien wie Caching und Nachrichtenwarteschlangen verwendet wird.

2. SETNX-Befehl

SETNX-Befehl wird verwendet, um einen Wert in Redis festzulegen. Er kann nur erfolgreich festgelegt werden, wenn der Schlüssel nicht vorhanden ist. Mit diesem Befehl können auch verteilte Sperren implementiert werden.

3. EXPIRE-Befehl

EXPIRE-Befehl wird verwendet, um die Ablaufzeit für einen Schlüssel festzulegen. Sobald er abläuft, wird der Schlüssel automatisch gelöscht.

4. DEL-Befehl

DEL-Befehl wird verwendet, um einen Schlüssel und seinen entsprechenden Wert zu löschen.

2. Wie Redis verteilte Sperren implementiert

Redis kann verteilte Sperren über den SETNX-Befehl implementieren. Die spezifischen Implementierungsschritte sind:

1. Bei der Anforderung, eine Sperre zu erhalten, sendet der Client einen SETNX-Befehl an Redis, um das Festlegen eines Schlüssels und das Festlegen der Ablaufzeit anzufordern. Wenn der Schlüssel nicht vorhanden ist, ist die Einstellung erfolgreich und der Client erhält die Sperre.
2. Wenn SETNX fehlschlägt, bedeutet dies, dass der Schlüssel bereits vorhanden ist und der Client die Sperre nicht erhalten konnte.
3. Nach dem Erwerb der Sperre muss der Client kontinuierlich Heartbeat-Pakete senden, um die Gültigkeit der Sperre aufrechtzuerhalten.
4. Wenn der Client die Sperre aufhebt, muss er einen DEL-Befehl an Redis senden, um den Schlüssel zu löschen.

3. Leistungsvergleich verteilter Redis-Sperren

Um die Leistung verschiedener Redis-Implementierungen verteilter Sperren zu vergleichen, haben wir ein Benchmark-Testmodell verwendet, das Folgendes umfasst:

1. Verwendung eines einzelnen Redis-Knotentests.
2. Testen Sie mit Redis Cluster.
3. Verwenden Sie mehrere Client-Tests, die jeweils auf zwei Redis-Knoten ausgeführt werden.

Durch das Testen der oben genannten drei Modelle haben wir die folgenden Ergebnisse erhalten.

1. Einzelner Redis-Knotentest

Auf einem einzelnen Redis-Knoten verwenden wir einen einzelnen Client zum Testen und stellen die Sperrzeit auf 1 Sekunde ein. Die Testergebnisse lauten wie folgt:

• Anzahl der Anfragen zum erfolgreichen Erhalten der Sperre: 498614
• Betriebszeit: 10,02 Sekunden

2. Redis-Cluster-Test

Auf dem Redis-Cluster verwenden wir acht Knoten zum Testen und Festlegen die Sperrzeit auf 1 Sekunde. Die Testergebnisse lauten wie folgt:

• Anzahl der Anfragen zum erfolgreichen Erwerb der Sperre: 337854
• Betriebszeit: 10,11 Sekunden

3. Mehrere Client-Tests

Wir haben zwei Clients auf zwei unabhängigen Redis-Knoten gestartet, die jeder Client sendet 1000 Anfragen. Zwei Clients konkurrieren jeweils mit dem SET-Befehl um einen Schlüssel zur Implementierung verteilter Sperren. Wenn einer der Clients einen SET-Befehl sendet, sendet der andere Client eine GET-Anfrage, um zu überprüfen, ob der Schlüssel vorhanden ist. Wenn er nicht vorhanden ist, sendet der Client den SET-Befehl erneut. Die Testergebnisse lauten wie folgt:

• Anzahl der Anfragen zum erfolgreichen Erwerb der Sperre: 7220
• Betriebszeit: 1,66 Sekunden

IV. Fazit

Nach dem Test können wir folgende Schlussfolgerungen ziehen:

1. Zu a einzelner Redis-Knoten. Es gibt fast keinen Leistungsunterschied zwischen verteilten Sperrimplementierungen.
2. Auf dem Redis-Cluster unterscheidet sich die Leistung der verteilten Sperrimplementierung geringfügig, ist jedoch nicht sehr offensichtlich.
3. Beim Test mehrerer Clients ist die Leistung der verteilten Sperre basierend auf dem SETNX-Befehl schlecht. Wenn die Parallelität gering ist, ist die Stabilität besser, aber wenn die Parallelität groß ist, führt dies zu einer großen Anzahl von Wiederholungsversuchen und Fehler.

Zusammenfassend lässt sich sagen, dass die Leistung der verteilten Sperrimplementierung auf Basis von SETNX nicht ideal ist. Um die Leistung zu verbessern, können Sie die Verwendung des Redlock-Algorithmus in Betracht ziehen, der mehrere Redis-Knoten zur Implementierung verteilter Sperren verwendet und eine stabilere Leistung bietet. Wir müssen jedoch basierend auf der tatsächlichen Situation die verteilte Sperrimplementierung auswählen und implementieren, die am besten zu uns passt.

Das obige ist der detaillierte Inhalt vonLeistungsvergleich verteilter Sperren, die von Redis implementiert wurden. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!