VERWERFEN Transaktion abbrechen, Transaktionsausführung abbrechen. Alle Befehle innerhalb des Blocks. |
|
EXEC
Führen Sie Befehle in allen Transaktionsblöcken aus. |
|
MULTI
Markiert den Beginn eines Transaktionsblocks. |
|
UNWATCH
Beenden Sie die Überwachung aller Tasten durch den WATCH-Befehl. |
|
WATCH-Taste [Taste …]
Überwacht einen (oder mehrere) Schlüssel. Wenn dieser (oder diese) Schlüssel vor der Ausführung der Transaktion durch andere Befehle geändert werden, wird die Transaktion unterbrochen. |
|
Fall
Normale Ausführung
Transaktion abbrechen
Alles hintereinander
Ein Fehler, alles hintereinander, nicht ausgeführt
Der Gläubiger des Feindes
Was dieses Problem betrifft, wie ist die Unterstützung von Redis für Transaktionen zu verstehen? Redis unterstützt teilweise Transaktionen. In diesem Teil werden die richtigen Transaktionen ausgeführt und die falschen nicht. Fall: Überwachung überwachen. Pessimistische Sperre /optimistische Sperre/CAS(Überprüfen und festlegen)
Pessimistische Sperre ist, wie der Name schon sagt, sehr pessimistisch. Jedes Mal, wenn Sie die Daten abrufen, denken Sie, dass andere sie ändern werden, also werden Sie sie jedes Mal sperren Sie erhalten die Daten, damit andere sie erhalten möchten. Diese Daten werden blockiert, bis sie die Sperre erhalten. Viele solcher Sperrmechanismen werden in herkömmlichen relationalen Datenbanken verwendet, z. B. Zeilensperren, Tabellensperren, Lesesperren, Schreibsperren usw., die alle vor Operationen gesperrt werden.
Tabellensperre: Sperren Sie die gesamte Tabelle. Zu diesem Zeitpunkt muss ein Prozess jedoch umfangreiche Änderungen vornehmen, was dazu führt, dass immer mehr Threads in die Warteschlange gestellt werden. Zeilensperre: Sperren Sie jeden Datensatz. Optimistische Sperre Sperren Sie es, aber beim Aktualisieren wird beurteilt, ob andere die Daten in diesem Zeitraum aktualisiert haben, und es können Mechanismen wie Versionsnummern verwendet werden. Optimistisches Sperren eignet sich für Anwendungstypen mit mehreren Lesevorgängen, wodurch der Durchsatz verbessert werden kann. Optimistische Sperrstrategie: Die übermittelte Version muss größer als die aktuelle Version des Datensatzes sein, bevor das Update durchgeführt werden kann.
Optimistische Sperre ist nicht blind optimistisch. Beispielsweise ändert Zhang San sein WeChat-Konto und Li Si ändert sein QQ-Konto Zu Beginn waren die Versionsnummern alle 1, dann hat Zhang San die Änderung der WeChat-ID abgeschlossen und sie übermittelt. Zu diesem Zeitpunkt änderte sich die Versionsnummer von 1 auf 2. Li Si übermittelte sie ebenfalls, nachdem er die Änderung abgeschlossen hatte. Zu diesem Zeitpunkt führt die Änderung von 1 zu 3 zu einer Ausnahme und wird erneut geändert. Optimistisches Sperren wird im Allgemeinen bei der Arbeit verwendet
um den verfügbaren Saldo und den ausstehenden Saldo von Kreditkarten zu initialisieren
Keine Manipulation, zuerst überwachen und dann Multi öffnen, um sicherzustellen, dass die beiden Betragsänderungen innerhalb derselben Transaktion erfolgen
Während der Überwachung wurde festgestellt, dass eine andere Transaktion die gemeinsam genutzten Daten geändert hat, was dazu führte, dass die Transaktionsausführung fehlschlug. Bevor Sie die Daten ändern, müssen Sie die Uhr sperren, da sonst ein Fehler auftritt. Wenn jemand meine Daten ändert, werde ich eine Ausnahme melden. Es liegt eine Manipulation vor.Der Schlüssel wird überwacht. Die Ausführung der nächsten Transaktion ist ungültig Die vor der Ausführung von exec hinzugefügte Sperre wird abgebrochen Von anderen Clients gedrückt/gepoppt, wird die gesamte Transaktionswarteschlange nicht ausgeführt. Mehrere Schlüssel werden durch den WATCH-Befehl überwacht, 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 Nullmulti- werden zurückgegeben, um den Anrufer darüber zu informieren, dass die Transaktionsausführung fehlgeschlagen ist
3 Phasen
• Öffnen: Starten Sie eine Transaktion mit MULTI
• In die Warteschlange stellen: Diese Befehle werden nicht ausgeführt Unmittelbar nach dem Empfang wird es stattdessen in die Transaktionswarteschlange gestellt und wartet auf die Ausführung
• Ausführung: Die Transaktion wird durch den EXEC-Befehl ausgelöst der Reihe nach ausgeführt. Während der Ausführung der Transaktion wird diese nicht durch Befehlsanfragen anderer Clients unterbrochen. Es gibt kein Konzept der Isolationsstufe: Die Befehle in der Warteschlange werden vor der Übermittlung nicht tatsächlich ausgeführt, da vor der Übermittlung der Transaktion keine Anweisungen tatsächlich ausgeführt werden, sodass keine „Abfragen innerhalb der Transaktion erforderlich sind, um sie anzuzeigen“. Aktualisierungen können nicht gesehen werden, wenn sie außerhalb der Transaktion abgefragt werden. Dies ist ein sehr problematisches Problem. Die Atomarität ist nicht garantiert: Wenn ein Befehl in derselben Redis-Transaktion nicht ausgeführt werden kann, werden nachfolgende Befehle trotzdem ohne Rollback ausgeführt. Die KI wird im herkömmlichen ACID nicht befolgt