Einführung in Redis-Transaktionen und zugehörige Befehle

1. Übersicht:

Wie viele andere Datenbanken bietet auch Redis als NoSQL-Datenbank einen Transaktionsmechanismus. In Redis sind die vier Befehle MULTI/EXEC/DISCARD/WATCH der Eckpfeiler unserer Transaktionsimplementierung. Ich glaube, dass dieses Konzept Entwicklern mit Erfahrung in der relationalen Datenbankentwicklung nicht unbekannt ist. Dennoch werden wir die Implementierungsmerkmale von Transaktionen in Redis kurz auflisten: (Empfohlen: Redis-Video-Tutorial)

1 ). Alle Befehle in der Transaktion werden in serieller Reihenfolge ausgeführt. Während der Ausführung der Transaktion stellt Redis keine Dienste für andere Clientanforderungen bereit und stellt so sicher, dass alle Befehle in der Transaktion atomar ausgeführt werden.

2) Im Vergleich zu Transaktionen in relationalen Datenbanken werden nachfolgende Befehle weiterhin ausgeführt, wenn in einer Redis-Transaktion ein Befehl fehlschlägt.

3). Wir können eine Transaktion über den MULTI-Befehl starten, den Personen mit Erfahrung in der relationalen Datenbankentwicklung als „BEGIN TRANSACTION“-Anweisung verstehen können. Die nach dieser Anweisung ausgeführten Befehle werden als Vorgänge innerhalb der Transaktion betrachtet. Schließlich können wir alle Vorgänge innerhalb der Transaktion festschreiben/zurücksetzen, indem wir den Befehl EXEC/DISCARD ausführen. Diese beiden Redis-Befehle können als Äquivalent zur COMMIT/ROLLBACK-Anweisung in einer relationalen Datenbank angesehen werden.

4). Wenn vor dem Start der Transaktion ein Kommunikationsfehler zwischen dem Client und dem Server auftritt und die Netzwerkverbindung unterbrochen wird, werden alle nachfolgend auszuführenden Anweisungen nicht vom Server ausgeführt. Wenn jedoch das Netzwerkunterbrechungsereignis auftritt, nachdem der Client den EXEC-Befehl ausgeführt hat, werden alle Befehle in der Transaktion vom Server ausgeführt.

5). Bei Verwendung des Append-Only-Modus schreibt Redis in diesem Aufruf alle Schreibvorgänge in der Transaktion auf die Festplatte, indem es die Systemfunktion write aufruft. Kommt es jedoch während des Schreibvorgangs zu einem Systemabsturz, beispielsweise bei einem Ausfall durch einen Stromausfall, kann es sein, dass zu diesem Zeitpunkt nur ein Teil der Daten auf die Festplatte geschrieben wird, während ein anderer Teil der Daten verloren geht.

Der Redis-Server führt beim Neustart eine Reihe notwendiger Konsistenzprüfungen durch. Sobald ein ähnliches Problem gefunden wird, wird er sofort beendet und gibt eine entsprechende Fehlermeldung aus. Zu diesem Zeitpunkt müssen wir das im Redis-Toolkit bereitgestellte Tool redis-check-aof vollständig nutzen. Dieses Tool kann uns dabei helfen, Dateninkonsistenzfehler zu lokalisieren und einige der geschriebenen Daten zurückzusetzen. Nach der Reparatur können wir den Redis-Server erneut neu starten.

2. Liste verwandter Befehle:

Befehlsprototyp	Zeitkomplexität	Befehlsbeschreibung	Rückgabewert
M U L T I		wird verwendet, um den Start einer Transaktion zu markieren. Alle danach ausgeführten Befehle werden in der Befehlswarteschlange gespeichert. Diese Befehle werden erst atomar ausgeführt, wenn EXEC ausgeführt wird.	Immer OK
E X E C		Führen Sie alle Befehle in der Befehlswarteschlange innerhalb einer Transaktion aus und stellen Sie dabei den Status der aktuellen Verbindung auf den Normalzustand, also den nicht-transaktionalen Zustand, wieder her. Wenn der WATCH-Befehl während einer Transaktion ausgeführt wird, kann der EXEC-Befehl nur dann alle Befehle in der Transaktionswarteschlange ausführen, wenn die von WATCH überwachten Schlüssel nicht geändert wurden. Andernfalls bricht EXEC alle Befehle in der aktuellen Transaktion ab.	Gibt die Ergebnisse jedes Befehls in der Transaktion atomar zurück. Wenn WATCH in einer Transaktion verwendet wird, gibt EXEC eine NULL-Multi-Bulk-Antwort zurück, sobald die Transaktion abgebrochen wird.
D I S C A R D		Rollen Sie alle Befehle in der Transaktionswarteschlange zurück und stellen Sie gleichzeitig den Status der aktuellen Verbindung auf den Normalzustand, dh den Nicht-Transaktionsstatus, wieder her. Wenn der WATCH-Befehl verwendet wird, werden mit diesem Befehl alle Schlüssel UNWATCH.	Immer OK.
W A T C H k e y [key ...]	O(1)	wird im ausgeführt MULTI-Befehl Bisher konnten Sie die zu überwachenden Schlüssel angeben. Wenn die überwachten Schlüssel jedoch vor der Ausführung von EXEC geändert werden, gibt EXEC die Ausführung aller Befehle in der Transaktionswarteschlange auf.	Immer OK.
U N W A T C H	O(1)	Stornieren Sie die angegebenen überwachten Schlüssel in der aktuellen Transaktion. Wenn der Befehl EXEC oder DISCARD ausgeführt wird, besteht keine Notwendigkeit um den Befehl manuell auszuführen, da danach alle überwachten Schlüssel in der Transaktion automatisch storniert werden.	Immer OK.

3. Befehlsbeispiele:

1. Die Transaktion wird normal ausgeführt:
#Führen Sie das Redis-Client-Tool unter der Shell-Befehlszeile aus.

 /> redis-cli

#Starten Sie eine neue Transaktion auf der aktuellen Verbindung.

redis 127.0.0.1:6379> multi
OK

#Führen Sie den ersten Befehl in der Transaktion aus. Am Rückgabeergebnis des Befehls können wir erkennen, dass der Befehl nicht sofort ausgeführt wird, sondern in der Befehlswarteschlange der Transaktion gespeichert wird.

redis 127.0.0.1:6379> incr t1
QUEUED

#Ein neuer Befehl wird ausgeführt. Wie aus dem Ergebnis hervorgeht, wird der Befehl auch in der Befehlswarteschlange der Transaktion gespeichert.

redis 127.0.0.1:6379> incr t2
QUEUED

#Führen Sie alle Befehle in der Transaktionsbefehlswarteschlange aus. Wie aus den Ergebnissen ersichtlich ist, werden die Ergebnisse der Befehle in der Warteschlange zurückgegeben.

redis 127.0.0.1:6379> exec
1) (integer) 1
2) (integer) 1

2. In der Transaktion ist ein Befehl fehlgeschlagen:
#Eine neue Transaktion starten.

redis 127.0.0.1:6379> multi
OK

#Setzen Sie den Wert von Schlüssel a auf 3 vom Typ Zeichenfolge.

redis 127.0.0.1:6379> set a 3
QUEUED

# Entfernen Sie das Element aus dem Kopf des mit Schlüssel a verknüpften Werts. Da der Wert ein Zeichenfolgentyp ist und der Befehl lpop nur für den Listentyp verwendet werden kann, wenn die Ausführung ausgeführt wird Befehl, der Befehl schlägt fehl.

redis 127.0.0.1:6379> lpop a
QUEUED

# Setzen Sie den Wert von Schlüssel a erneut auf String 4.

redis 127.0.0.1:6379> set a 4
QUEUED

#Rufen Sie den Wert von Schlüssel a ab, um zu bestätigen, ob der Wert durch den zweiten Set-Befehl in der Transaktion erfolgreich festgelegt wurde.

redis 127.0.0.1:6379> get a
QUEUED

# Aus den Ergebnissen geht hervor, dass der zweite Befehl lpop in der Transaktion nicht ausgeführt werden konnte, die nachfolgenden Set- und Get-Befehle jedoch erfolgreich ausgeführt wurden. Dies ist der Transaktions- und Beziehungstyp von Redis . Der wichtigste Unterschied zwischen Transaktionen in einer Datenbank.
redis 127.0.0.1:6379> exec
1) OK
2) (Fehler) ERR Operation gegen einen Schlüssel, der den falschen Wert enthält
3) OK
4) „4“
3. Rollback-Transaktion:
#Legen Sie einen Wert für Schlüssel t2 fest, bevor die Transaktion ausgeführt wird.

redis 127.0.0.1:6379> set t2 tt
OK

#Starten Sie eine Transaktion.

redis 127.0.0.1:6379> multi
OK

# Legen Sie innerhalb der Transaktion einen neuen Wert für diesen Schlüssel fest.

redis 127.0.0.1:6379> set t2 ttnew
QUEUED

#Brechen Sie die Transaktion ab.

redis 127.0.0.1:6379> discard
OK

#Sehen Sie sich den Wert des Schlüssels t2 an. Aus den Ergebnissen können wir ersehen, dass der Wert dieses Schlüssels immer noch der Wert vor Beginn der Transaktion ist.

redis 127.0.0.1:6379> get t2
"tt"

4. WATCH-Befehl und CAS-basiertes optimistisches Sperren:

In Redis-Transaktionen kann der WATCH-Befehl verwendet werden, um CAS bereitzustellen ( Check-and-Set-Funktion. Gehen Sie davon aus, dass wir mehrere Schlüssel über den WATCH-Befehl überwachen, bevor die Transaktion ausgeführt wird. Wenn sich der Wert eines Schlüssels nach WATCH ändert, wird die durch den EXEC-Befehl ausgeführte Transaktion abgebrochen und eine Null-Multi-Bulk-Antwort zurückgegeben, um den Aufrufer zu benachrichtigen der Transaktion ist fehlgeschlagen.

Zum Beispiel gehen wir erneut davon aus, dass der Befehl incr in Redis nicht bereitgestellt wird, um die atomare Inkrementierung von Schlüsselwerten abzuschließen. Wenn wir diese Funktion implementieren möchten, können wir nur den entsprechenden Code selbst schreiben. Der Pseudocode lautet wie folgt:

      val = GET mykey
      val = val + 1
      SET mykey $val

Der obige Code kann nur garantieren, dass das Ausführungsergebnis bei einer einzelnen Verbindung korrekt ist, denn wenn mehrere Clients diesen Code gleichzeitig ausführen Dann kommt es zu einem Fehlerszenario, das häufig in Multithread-Programmen auftritt – Race Condition (Race Condition).

Zum Beispiel lesen Clients A und B beide gleichzeitig den ursprünglichen Wert von mykey. Gehen Sie davon aus, dass der Wert 10 ist. Danach addieren beide Clients eins zum Wert und setzen ihn auf den Redis-Server zurück . Dies führt dazu, dass das Ergebnis von mykey 11 ist und nicht 12, wie wir denken. Um ähnliche Probleme zu lösen, benötigen wir die Hilfe des WATCH-Befehls, siehe folgenden Code:

      WATCH mykey
      val = GET mykey
      val = val + 1
      MULTI
      SET mykey $val
      EXEC

Der Unterschied zum vorherigen Code besteht darin, dass der neue Code den Wert von mykey über WATCH überwacht Geben Sie den Befehl ein, bevor Sie den Schlüssel erhalten, und umgeben Sie dann den Befehl set in einer Transaktion. Dadurch kann effektiv sichergestellt werden, dass vor der Ausführung von EXEC für jede Verbindung der EXEC-Befehl ausgeführt wird, wenn der von der aktuellen Verbindung erhaltene Wert von mykey von anderen verbundenen Clients geändert wird Die aktuelle Verbindung wird nicht ausgeführt. Auf diese Weise kann der Anrufer nach Beurteilung des Rückgabewerts feststellen, ob val erfolgreich zurückgesetzt wurde.

Weitere Redis-Kenntnisse finden Sie in der Spalte Redis-Tutorial.

Das obige ist der detaillierte Inhalt vonEinführung in Redis-Transaktionen und zugehörige Befehle. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!