Redis Pit Prevention Guide – Transaktionen

Verwandte Befehlseinführung:

(Lernvideo-Sharing: Redis-Video-Tutorial)

Hinweis:

------MULTI, EXEC, DISCARD sind diejenigen, die Transaktionen explizit öffnen und steuern Häufig verwendete Befehle können mit BEGAIN, COMMIT und ROLLBACK in relationalen Datenbanken verglichen werden (tatsächlich gibt es eine große Lücke). verursacht durch Transaktions-Parallelitätsproblem (einfach als Sperren des Schlüssels verstanden);

Redis-Transaktion

MULTI, EXEC, DISCARD und WATCH sind die Grundlage von Redis-Transaktionen. Sie werden zum expliziten Starten und Steuern einer Transaktion verwendet und ermöglichen die Ausführung einer Reihe von Befehlen in einem Schritt. Und bietet zwei wichtige Garantien:

Alle Befehle in der Transaktion werden serialisiert und der Reihe nach ausgeführt. Während der Ausführung einer Redis-Transaktion erfolgt keine Anfrage eines anderen Clients. Dadurch wird sichergestellt, dass die Befehlswarteschlange als einzelne atomare Operation ausgeführt wird.

Befehle in der Warteschlange werden entweder alle verarbeitet oder ignoriert. Der EXEC-Befehl löst daher die Ausführung aller Befehle in der Transaktion aus, wenn die Verbindung des Clients mit dem Server vor dem Aufruf des MULTI-Befehls unterbrochen wird Dann werden alle Befehle ausgeführt.

Gleichzeitig verwendet Redis AOF (Append-Only File), um Transaktionen mithilfe eines zusätzlichen Schreibvorgangs auf die Festplatte zu schreiben. Wenn eine Ausfallzeit oder ein Prozessabsturz auftritt, können Sie das Redis-Check-Aof-Tool verwenden, um die Nur-Anhänge-Datei zu reparieren, sodass der Dienst normal starten und einige Vorgänge wieder aufnehmen kann.

Verwendung

Verwenden Sie den MULTI-Befehl, um explizit eine Redis-Transaktion zu starten. Dieser Befehl antwortet immer mit OK. Zu diesem Zeitpunkt kann der Benutzer mehrere Befehle ausgeben, und Redis führt diese Befehle nicht aus, sondern stellt sie in die Warteschlange. Nach dem Aufruf von EXEC werden alle Befehle ausgeführt. Durch den Aufruf von DISCARD kann die Befehlswarteschlange in der Transaktion geleert und die Transaktion beendet werden.

Das folgende Beispiel erhöht atomar die Tasten foo und bar.

>MULTI
OK
>INCR foo
QUEUED
>INCR bar
QUEUED
>EXEC
1）（整数）1
2）（整数）1

Wie aus der obigen Befehlsausführung ersichtlich ist, gibt EXEC ein Array zurück, wobei jedes Element das Rückgabeergebnis eines einzelnen Befehls in der Transaktion ist und die Reihenfolge mit der Reihenfolge übereinstimmt, in der der Befehl ausgegeben wurde. Wenn eine Redis-Verbindung im Kontext einer MULTI-Anfrage steht, werden alle Befehle mit der Zeichenfolge QUEUED (aus Sicht des Redis-Protokolls als Statusantwort gesendet) beantwortet und in der Befehlswarteschlange eingereiht. Nur wenn EXEC aufgerufen wird, werden die in der Warteschlange befindlichen Befehle ausgeführt und das tatsächliche Ergebnis wird zu diesem Zeitpunkt zurückgegeben.

Fehler in Transaktionen

Während einer Transaktion können zwei Arten von Befehlsfehlern auftreten:

Vor dem Aufruf des EXEC-Befehls ist ein Fehler aufgetreten (Befehlswarteschlange fehlgeschlagen). Der Befehl kann beispielsweise Syntaxfehler aufweisen (falsche Anzahl von Parametern, falscher Befehlsname usw.) oder es liegen bestimmte kritische Bedingungen vor, z. B. unzureichender Speicher (wenn der Server über Speicherbeschränkungen verfügt, die die maxmemory-Direktive verwenden).

Der Client erkennt den ersten Fehler vor dem EXEC-Aufruf. Durch Überprüfen der Statusantwort des in der Warteschlange befindlichen Befehls (***Hinweis: Dies bezieht sich auf die Statusantwort in der Warteschlange, nicht auf das Ausführungsergebnis***). Wenn der Befehl mit „QUEUED“ antwortet, wurde er korrekt in die Warteschlange gestellt, andernfalls gibt Redis eine zurück Fehler. Wenn beim Einreihen eines Befehls in die Warteschlange ein Fehler auftritt, brechen die meisten Clients die Transaktion ab und leeren die Befehlswarteschlange. Allerdings:

Vor Redis 2.6.5 führte der Client in diesem Fall nach dem Aufruf des EXEC-Befehls eine Teilmenge der Befehle aus (diejenigen, die erfolgreich in die Warteschlange gestellt wurden) und ignorierte frühere Fehler. Ab Redis 2.6.5 merkt sich der Server Fehler, die während der Anhäufung von Befehlen aufgetreten sind. Wenn der EXEC-Befehl aufgerufen wird, verweigert er die Ausführung der Transaktion und gibt diese Fehler zurück, während die Befehlswarteschlange automatisch geleert wird. Ein Beispiel lautet wie folgt:

>MULTI
+OK
>INCR a b c
-ERR wrong number of arguments for 'incr' command

Dies ist auf einen Syntaxfehler im INCR-Befehl zurückzuführen, der vor dem Aufruf von EXEC und dem Beenden der Transaktion erkannt wird (Version 2.6.5+).

Der Fehler trat nach dem Aufruf des EXEC-Befehls auf. Zum Beispiel die Verwendung eines falschen Werts, um eine Operation für einen Schlüssel auszuführen (z. B. das Aufrufen einer Listenoperation für einen String-Wert).

Fehler, die nach der Ausführung des EXEC-Befehls auftreten, werden nicht speziell behandelt: auch wenn einige Befehle in der Wenn die Transaktion nicht ausgeführt werden kann, werden andere Befehle weiterhin normal ausgeführt.

Das Beispiel sieht wie folgt aus:

>MULTI
+OK
>SET a 3
+QUEUED
>LPOP a
+QUEUED
>EXEC
*2
+OK
-ERR Operation against a key holding the wrong kind of value

EXEC gibt ein String-Array zurück, das zwei Elemente enthält, ein Element ist OK, das andere ist -ERR…. Ob Fehler ordnungsgemäß an Benutzer zurückgegeben werden können, hängt von der Implementierung der Clientbibliothek (z. B. Spring-data-redis.redisTemplate) ab. Es ist zu beachten, dass selbst wenn der Befehl fehlschlägt, alle anderen Befehle in der Warteschlange verarbeitet werden – Redis stoppt die Verarbeitung des Befehls nicht.

Redis-Transaktionen unterstützen kein Rollback (Hervorhebung)

Tatsächlich können Redis-Befehle während der Transaktionsausführung fehlschlagen, die verbleibenden Befehle werden jedoch weiterhin anstelle von Rollback (Transaktions-Rollback) ausgeführt. Wenn Sie relationale Datenbanken verwendet haben, kommt Ihnen diese Situation möglicherweise seltsam vor. Es gibt jedoch eine gute Erklärung für diese Situation:

Redis命令可能会执行失败，仅仅是由于错误的语法被调用（命令排队时检测不出来的错误），或者使用错误的数据类型操作某个Key： 这意味着，实际上失败的命令都是编程错误造成的，都是开发中能够被检测出来的，生产环境中不应该存在。（这番话，彻底甩锅，“都是你们自己编程错误，与我们无关”。）由于不必支持Rollback,Redis内部简洁并且更加高效。

“如果错误就是发生了呢？”这是一个反对Redis观点的争论。然而应该指出的是，通常情况下，回滚并不能挽救编程错误。鉴于没有人能够挽救程序员的错误，并且Redis命令失败所需的错误类型不太可能进入生产环境，所以我们选择了不支持错误回滚（Rollback）这种更简单快捷的方法。

清除命令队列

DISCARD被用来中止事务。事务中的所有命令将不会被执行,连接将恢复正常状态。

> SET foo 1
OK
> MULTI
OK
> INCR foo
QUEUED
> DISCARD
OK
> GET foo
"1"

相关推荐：redis数据库教程

Das obige ist der detaillierte Inhalt vonRedis Pit Prevention Guide – Transaktionen. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!