Alle Vorgänge in der Transaktion sind in der Datenbank unteilbar, entweder sind alle abgeschlossen oder keine wird ausgeführt.
Die Ausführung einer Transaktion wandelt Daten von einem Zustand in einen anderen um, bevor die Transaktion beginnt und nachdem die Transaktion endet, werden die Integritätsbeschränkungen der Datenbank nicht verletzt.
Die Isolation von Transaktionen erfordert, dass die Objekte jeder Lese-/Schreibtransaktion von den Operationsobjekten anderer Transaktionen getrennt werden, dh die Transaktion ist vor der Übermittlung für andere Transaktionen nicht sichtbar.
Nachdem die Datenbank eine Transaktion ausgeführt hat, müssen die Datenänderungen beibehalten und gespeichert werden. Beim Neustart der Datenbank muss der Wert der Daten der geänderte Wert sein.
Die Ausführung von Redis-Transaktionen umfasst die folgenden drei Schritte:
Der Client verwendet den MULTI-Befehl, um eine Transaktion explizit zu starten.
Der Server empfängt die vom Client gesendeten spezifischen Vorgänge (z. B. das Hinzufügen, Löschen und Ändern von Daten) und führt sie in der Transaktion aus. Bei diesen Vorgängen handelt es sich um die von Redis selbst bereitgestellten Datenlese- und -schreibbefehle. Obwohl diese Befehle vom Client an den Server gesendet werden, speichert die Redis-Instanz diese Befehle nur vorübergehend in einer Befehlswarteschlange und führt sie nicht sofort aus.
Nur wenn ein EXEC-Befehl empfangen und ausgeführt wird, schreibt Redis die Transaktion fest und führt tatsächlich alle Befehle in der Transaktionswarteschlange aus.
MULTI: Öffnen Sie eine Transaktion
EXEC: Senden Sie die Transaktion und führen Sie alle Betriebsbefehle in der Befehlswarteschlange aus.
DISCARD: Eine Transaktion abbrechen und die Befehlswarteschlange löschen, aber kein Transaktions-Rollback unterstützen.
WATCH: Erkennen Sie, ob sich der Wert eines oder mehrerer Schlüssel während der Ausführung der Transaktion ändert. Wenn er sich ändert, bricht die aktuelle Transaktion die Ausführung ab.
Szenario 1: Beim Hinzufügen der Transaktion zur Warteschlange wird ein Fehler gemeldet. Anschließend gibt Redis die Transaktionsausführung auf, um die Atomizität der Transaktion sicherzustellen.
Szenario 2: Der Befehl meldet keinen Fehler, wenn er in die Warteschlange eingegeben wird, sondern einen Fehler, wenn er tatsächlich ausgeführt wird. Die Atomizität der Transaktion kann nicht garantiert werden.
Beispielbeschreibung für Fall eins
127.0.0.1:6379> multi OK 127.0.0.1:6379> set t1 v1 QUEUED 127.0.0.1:6379> set t2 v2 QUEUED 127.0.0.1:6379> setget t3 (error) ERR unknown command 'setget' 127.0.0.1:6379> set t4 v4 QUEUED 127.0.0.1:6379> exec (error) EXECABORT Transaction discarded because of previous errors. 127.0.0.1:6379> get t4 (nil)
Erklärung: Wenn vor der Ausführung des exec-Befehls ein Syntaxfehler auftritt (ein nicht vorhandener Befehl wird verwendet), meldet Redis beim Einreihen des Befehls einen Fehler und zeichnet den auf Fehler und warten Sie, bis der Exec-Befehl ausgeführt wird. Anschließend lehnt Redi alle übermittelten Befehle ab und die Transaktionsausführung schlägt fehl. In diesem Fall kann die Transaktion von Reid die Atomizität unterstützen.
Beispielbeschreibung für Fall 2
127.0.0.1:6379> multi OK 127.0.0.1:6379> incr s2 QUEUED 127.0.0.1:6379> set a1 v1 QUEUED 127.0.0.1:6379> set a2 v2 QUEUED 127.0.0.1:6379> exec 1) (error) ERR value is not an integer or out of range 2) OK 3) OK 127.0.0.1:6379> get a2 "v2"
Erläuterung: Der Wert von s2 ist v2, und beim Ausführen des Befehls incr wird ein Fehler gemeldet, da incr nur Werte vom Typ Ganzzahl hinzufügen kann Nachfolgende Befehle können nicht erfolgreich ausgeführt werden, sodass die Atomizität der Transaktion in diesem Fall nicht garantiert werden kann.
Im ersten Fall wird die Transaktion selbst abgebrochen, sodass die Konsistenz der Transaktion gewährleistet werden kann.
Im zweiten Fall wird der fehlerhafte Befehl nicht ausgeführt, der richtige Befehl kann jedoch normal ausgeführt werden , und die Konsistenz der Datenbank wird nicht geändert.
Wenn die Redis-Persistenz auf RDB eingestellt ist, wird der generierte RDB-Snapshot nicht ausgeführt, wenn die Transaktion ausgeführt wird, sodass die Ergebnisse des Transaktionsbefehlsvorgangs nicht gespeichert werden RDB-Snapshot: Wenn Sie den RDB-Snapshot zur Wiederherstellung verwenden, sind die Daten in der Datenbank ebenfalls konsistent.
Wenn die Reids-Persistenz auf AOF eingestellt ist und die Instanz fehlschlägt, bevor der Transaktionsvorgang im AOF-Protokoll aufgezeichnet wird, sind die mithilfe des AOF-Protokolls wiederhergestellten Datenbankdaten konsistent. Wenn nur einige Vorgänge im AOF-Protokoll aufgezeichnet werden, können wir redis-check-aof verwenden, um die abgeschlossenen Vorgänge in der Transaktion zu löschen, und die Datenbank ist nach der Wiederherstellung konsistent.
Um eine Redis-Transaktionsisolation zu erreichen, müssen Sie den Befehl watch verwenden. Das Prinzip von Watch besteht darin, dass der WATCH-Mechanismus vor der Ausführung einer Transaktion beim Überwachen von Änderungen in einem oder mehreren Schlüsseln, wenn die Transaktion den auszuführenden EXEC-Befehl aufruft, zunächst prüft, ob die überwachten Schlüssel von anderen Clients geändert wurden. Wenn der Wert des Listeners geändert wird, wird die Transaktionsausführung abgebrochen, um zu verhindern, dass die Isolation der Transaktion zerstört wird.
Beispielbeschreibung
Kunde 1:
127.0.0.1:6379> get blance "100" 127.0.0.1:6379> watch blance OK 127.0.0.1:6379> multi OK 127.0.0.1:6379> decrby blance 10 QUEUED 127.0.0.1:6379> incrby blance 10 QUEUED 127.0.0.1:6379> exec (nil)
Kunde 2:
127.0.0.1:6379> get blance "100" 127.0.0.1:6379> set blance 90 OK 127.0.0.1:6379> get blance "90"
Erläuterung: Nach dem Start der Transaktion führt Kunde 2 den Vorgang zur Änderung des Guthabenwerts durch, um andere Kunden zu simulieren Bei der Ausführung der Transaktion wurden die von der Uhr überwachten Daten geändert und dann der EXEC-Befehl von Client 1 ausgeführt. Es wurde festgestellt, dass die Transaktion nicht erfolgreich ausgeführt wurde.
Redis-Transaktionen können die Persistenz nicht unterstützen, nachdem eine Transaktion ausgeführt wurde und bevor der nächste RDB-Snapshot ausgeführt wird. In diesem Fall können die durch die Transaktion geänderten Daten nicht abstürzen Wenn Redis den AOF-Modus verwendet, kann es zu Datenverlusten kommen, wenn die Persistenzkonfiguration „Nein“, „Everysec“ und „Immer“ lautet. Daher kann die Haltbarkeit der Transaktion Sex dies nicht unterstützen.
Das obige ist der detaillierte Inhalt vonSo implementieren Sie Redis-Transaktionen. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!