1. Was ist Reverse Compensation? Lassen Sie mich zunächst einen Begriff erklären. Wenn Sie sich Informationen zu verteilten Transaktionen ansehen, werden Sie häufig auf einen Begriff stoßen:
Reverse Compensation. Was ist eine umgekehrte Kompensation?
Lassen Sie mich ein Beispiel geben: Angenommen, wir haben jetzt drei Microservices, nämlich A, B und C. Jetzt rufen wir die Dienste B und C jeweils in Dienst A auf. Um sicherzustellen, dass B und C gleichzeitig erfolgreich sind oder scheitern Zeit müssen wir die Verteilung formaler Angelegenheiten nutzen. Nach unserem bisherigen Verständnis lokaler Transaktionen tritt jedoch bei lokalen Transaktionen in B und C nach Abschluss und Übermittlung der Transaktion in Dienst B eine Ausnahme in der Transaktion in Dienst C auf, die jedoch zurückgesetzt werden muss eingereicht. Wie kann ich ein Rollback durchführen?
Bei dem Rollback, über das wir derzeit sprechen, handelt es sich eigentlich nicht um das traditionelle Rollback über das MySQL-Redo-Log,
sondern um die Verwendung eines Update-SQL, um die geänderten Daten in Dienst B wiederherzustellen.
Das nennen wir Reverse Compensation!
2. Grundlegende Konzeptüberprüfung
Es gibt drei Kernkonzepte in Seata:
TC (Transaktionskoordinator) – Transaktionskoordinator: verwaltet den Status globaler Transaktionen und Filialtransaktionen und steuert die globale Transaktionsübermittlung oder das Rollback.
-
TM (Transaktionsmanager) – Transaktionsmanager: Definieren Sie den Umfang globaler Transaktionen, starten Sie globale Transaktionen, übernehmen Sie globale Transaktionen oder setzen Sie sie zurück.
-
RM (Ressourcenmanager) – Ressourcenmanager: verwaltet die Ressourcen (Ressource) für die Verarbeitung von Filialtransaktionen, kommuniziert mit TC, um Filialtransaktionen zu registrieren und den Status von Filialtransaktionen zu melden, und steuert die Festschreibung oder das Rollback von Filialtransaktionen.
-
Dabei ist TC ein separat bereitgestellter Server und TM und RM sind in die Anwendung eingebettete Clients.
Schauen wir uns das folgende Bild an:
Dieses Bild erklärt im Grunde diese drei Konzepte klar. 
Ohne dieses Bild zu betrachten, können wir wahrscheinlich das Implementierungsprinzip verteilter Transaktionen erraten: Zuerst muss es einen globalen Transaktionskoordinator (TC) geben, und jede lokale Transaktion (RM) beginnt mit der Ausführung oder während der Ausführung Sobald er (TC) feststellt, dass alle lokalen Transaktionen erfolgreich ausgeführt wurden, benachrichtigt er den globalen Transaktionskoordinator rechtzeitig Wenn er feststellt, dass jemand diese Transaktion nicht ausgeführt hat, benachrichtigt er alle, gemeinsam einen Rollback durchzuführen (dieser Rollback ist natürlich nicht unbedingt ein echter Rollback, sondern eine umgekehrte Kompensation). Wann beginnt und endet eine Transaktion? Das heißt, wo liegen die Grenzen der Transaktion? Verteilte Transaktionen in Seata werden alle durch
-Anmerkungen implementiert. Mit anderen Worten: Wo sollte diese Anmerkung hinzugefügt werden? Der Ort zum Hinzufügen dieser Anmerkung ist eigentlich das Transaktionsmanager-TM.
Nach der obigen Einführung sollten Freunde verstehen, dass die Verwendung von Seata zur Implementierung verteilter Transaktionen nicht so schwierig ist wie gedacht und das Prinzip immer noch sehr einfach ist. @GlobalTransactional
Seata umfasst vier verschiedene Modi. Bei den vier als nächstes vorgestellten verschiedenen Modi geht es tatsächlich darum, wie ein Rollback durchgeführt werden kann, wenn eine lokale Transaktion fehlschlägt. Dies sind die vier verschiedenen verteilten Transaktionsmodi, über die wir später sprechen werden.
3. Was ist eine zweistufige Einreichung? Schauen Sie sich zunächst das Bild unten an:
Dieses Bild beinhaltet drei Konzepte:
AP: Es versteht sich von selbst, der AP ist die Anwendung selbst.
RM: RM ist der Ressourcenmanager, der an der Transaktion beteiligt ist. In den meisten Fällen handelt es sich um eine verteilte Transaktion, an der mehrere RMs beteiligt sind.
TM: TM ist der Transaktionsmanager, der verteilte Transaktionen erstellt und die Ausführung und den Status jeder Untertransaktion in der verteilten Transaktion koordiniert. Untertransaktionen beziehen sich auf bestimmte auf RM ausgeführte Vorgänge.
Was ist also Two-Phase Commit (kurz 2PC)? Die Wahrheit der zweistufigen Einreichung ist sehr einfach. Brother Song gibt Ihnen ein einfaches Beispiel, um die zweistufige Einreichung zu erklären:
Zum Beispiel das folgende Bild:
Wir nennen Lagerung und Ordnung Im Geschäftskonto müssen die Vorgänge in diesen drei Diensten gleichzeitig erfolgreich sein oder fehlschlagen. Da sich diese drei jedoch in unterschiedlichen Diensten befinden, können wir die Vorgänge in diesen drei Diensten nur separat ausführen lassen separat. Die erste von zwei Stufen.
Nachdem die erste Phase der Ausführung abgeschlossen ist, beeilen Sie sich nicht mit der Übermittlung, da einige der drei Dienste möglicherweise nicht ausgeführt wurden. Zu diesem Zeitpunkt müssen die drei Dienste die Ausführungsergebnisse ihrer ersten Phase einem Transaktionskoordinator melden . Wenn die erste Phase der drei Dienste erfolgreich ausgeführt wurde, wird der Transaktionskoordinator den drei Transaktionen zur Übermittlung mitgeteilt. Wenn einer der drei Dienste fehlschlägt, werden die drei Transaktionen zum Zurücksetzen aufgefordert jeweils.
Dies wird als zweiphasiges Commit bezeichnet.
Um es zusammenzufassen: Bei der zweistufigen Übermittlung wird die Transaktion in Teilnehmer unterteilt (z. B. jeder spezifische Dienst im Bild oben) und der Koordinator. Die Teilnehmer benachrichtigen den Koordinator über den Erfolg oder Misserfolg des Vorgangs und dann Der Koordinator trifft Entscheidungen auf der Grundlage der Feedbackinformationen aller Teilnehmer. Unabhängig davon, ob der Teilnehmer den Vorgang einreichen oder abbrechen möchte, kann der Teilnehmer hier als RM und der Koordinator als TM verstanden werden.
Die verschiedenen verteilten Transaktionsmodi in Seata basieren jedoch grundsätzlich auf der Grundlage der zweistufigen Übermittlung und sind daher nicht genau gleich. Dies muss von Freunden beachtet werden.
4. Der AT-Modus ist ein vollautomatischer Transaktions-Rollback-Modus.
Insgesamt ist der AT-Modus eine Weiterentwicklung des zweiphasigen Festschreibungsprotokolls:
Einphasig: Geschäftsdaten und Rollback-Protokolldatensätze werden in derselben lokalen Transaktion festgeschrieben, wodurch lokale Sperren und Verbindungsressourcen freigegeben werden.
Angenommen, es gibt ein Business-Tischprodukt wie folgt:
Jetzt wollen wir es tun Der folgende Aktualisierungsvorgang:
update product set name = 'GTS' where name = 'TXC';
Nach dem Login kopieren
Die Schritte sind wie folgt:
Phase eins:
SQL analysieren: SQL-Typ (UPDATE), Tabelle (Produkt), Bedingung (wobei Name = ') abrufen TXC') und andere verwandte Informationen. - Primärschlüssel
.
Rollback-Protokoll einfügen: Kombinieren Sie die Vor- und Nachher-Spiegeldaten und Geschäfts-SQL-bezogenen Informationen in einem Rollback-Protokolldatensatz und fügen Sie ihn in die UNDO_LOG-Tabelle ein.
Zweite Phase:
Die zweite Phase ist in zwei Situationen unterteilt: Commit oder Rollback.
Sehen wir uns zunächst die Rollback-Schritte an:
再来看提交步骤：
大致上就是这样一个步骤，思路还是比较清晰的，就是当你要更新一条记录的时候，系统将这条记录更新之前和更新之后的内容生成一段 JSON 并存入 undo log 表中，将来要回滚的话，就根据 undo log 中的记录去更新数据（反向补偿），将来要是不回滚的话，就删除 undo log 中的记录。
在整个过程中，开发者只需要额外创建一张 undo log 表就行了，然后给需要处理全局事务的地方加上 @GlobalTransactional
Submit Lokale Angelegenheiten. Und melden Sie das Ausführungsergebnis der lokalen Transaktion (dh das Ergebnis des Rollbacks der Zweigstellentransaktion) an TC.
Schauen wir uns noch einmal die Übermittlungsschritte an:
empfängt die Zweig-Übermittlungsanfrage von TC, stellt die Anforderung in eine asynchrone Aufgabenwarteschlange und gibt das erfolgreiche Übermittlungsergebnis sofort an TC zurück.
Branch-Übermittlungsanfragen in der asynchronen Aufgabenphase löschen die entsprechenden UNDO-LOG-Datensätze asynchron und stapelweise.
🎜🎜🎜Es ist im Grunde ein solcher Schritt. Wenn Sie einen Datensatz aktualisieren möchten, generiert das System einen JSON für den Inhalt vor und nach der Aktualisierung des Datensatzes und speichert ihn in der Undo-Log-Tabelle Sie möchten in Zukunft ein Rollback durchführen, aktualisieren Sie die Daten basierend auf den Datensätzen im Rückgängig-Protokoll (umgekehrte Kompensation). Wenn Sie in Zukunft kein Rollback durchführen möchten, löschen Sie die Datensätze im Rückgängig-Protokoll. 🎜🎜Im gesamten Prozess müssen Entwickler lediglich eine zusätzliche Rückgängig-Protokolltabelle erstellen und dann
@GlobalTransactional-Anmerkungen hinzufügen, wo globale Transaktionen verarbeitet werden müssen. 🎜🎜Andere Übermittlungen, Rollbacks und Rollbacks erfolgen alle vollautomatisch, was einfacher ist. Wenn Sie sich also für die Verwendung von Seata zur Abwicklung verteilter Transaktionen in Ihrem Projekt entscheiden, ist die Wahrscheinlichkeit, den AT-Modus zu verwenden, immer noch recht hoch. 🎜🎜5. Der TCC-Modus (Try-Confirm-Cancel) hat ein gewisses Maß an manuellem Charakter. Er ist ebenfalls zweistufig, unterscheidet sich jedoch vom AT. 🎜🎜🎜Auf der offiziellen Website gibt es ein Flussdiagramm von TCC. Werfen wir einen Blick darauf: 🎜🎜🎜🎜🎜🎜Wie Sie sehen können, ist TCC ebenfalls in zwei Phasen unterteilt: 🎜
Die erste Phase ist die Vorbereitung. In dieser Phase werden hauptsächlich Ressourcen wie Banküberweisungen erkannt und reserviert. In dieser Phase prüfen wir zunächst, ob das Geld des Benutzers ausreicht Wenn es ausreicht, wird es zuerst eingefroren.
Die zweite Stufe ist das Festschreiben oder Zurücksetzen. Dabei wird hauptsächlich darauf gewartet, dass die erste Stufe jeder Zweigtransaktion abgeschlossen ist. Nach Abschluss aller Ausführungen meldet TC seine eigene Situation Wenn TC feststellt, dass eine Filialtransaktion abnormal ist, benachrichtigen Sie alle zum Zurücksetzen.
Dann haben Ihre Freunde vielleicht herausgefunden, dass der obige Prozess insgesamt drei Methoden umfasst: Vorbereiten, Festschreiben und Zurücksetzen. Diese drei Methoden sind vollständig benutzerdefinierte Methoden und wir müssen sie selbst implementieren Der Anfang, dass TCC ein manueller Modus ist.
Im Vergleich zu AT haben alle festgestellt, dass der TCC-Modus tatsächlich nicht von der Transaktionsunterstützung der zugrunde liegenden Datenbank abhängt. Mit anderen Worten, es spielt keine Rolle, auch wenn Ihre zugrunde liegende Datenbank keine Transaktionen unterstützt Vorbereiten, Festschreiben und Zurücksetzen sind Die Entwickler haben es selbst geschrieben, und wir müssen nur die Prozesse glätten, die diesen drei Methoden entsprechen.
6. XA-Modus
Wenn Sie die XA-Transaktionen der MySQL-Datenbank verstehen, werden Sie verstehen, worum es beim XA-Modus in Seata geht.
Die XA-Spezifikation ist ein DTP-Standard (Distributed Transaction Processing), der von der X/Open-Organisation definiert wird.
Die XA-Spezifikation beschreibt die Schnittstelle zwischen dem globalen Transaktionsmanager und dem lokalen Ressourcenmanager. Der Zweck der XA-Spezifikation besteht darin, den Zugriff auf mehrere Ressourcen (z. B. Datenbanken, Anwendungsserver, Nachrichtenwarteschlangen usw.) in derselben Transaktion zu ermöglichen, sodass die ACID-Eigenschaften anwendungsübergreifend gültig bleiben.
Die XA-Spezifikation verwendet zweiphasiges Commit, um sicherzustellen, dass alle Ressourcen gleichzeitig eine bestimmte Transaktion festschreiben oder zurücksetzen.
Die XA-Spezifikation wurde Anfang der 1990er Jahre vorgeschlagen. Derzeit unterstützen fast alle Mainstream-Datenbanken die XA-Spezifikation.
XA-Transaktionen basieren auf dem zweiphasigen Commit-Protokoll. Um sicherzustellen, dass alle Transaktionsteilnehmer die Vorbereitungsarbeiten (erste Phase) abgeschlossen haben, ist ein Transaktionskoordinator erforderlich. Wenn der Koordinator eine Nachricht erhält, dass alle Teilnehmer bereit sind, benachrichtigt er ihn darüber, dass alle Transaktionen festgeschrieben werden können (Phase 2). MySQL spielt bei dieser XA-Transaktion die Rolle eines Teilnehmers, nicht des Koordinators (Transaktionsmanagers).
Die XA-Transaktionen von MySQL sind in internes XA und externes XA unterteilt. Externes Commit muss sein Die Informationen werden in das Binärprotokoll geschrieben, bei dem es sich um eine verteilte interne XA-Transaktion handelt, mit der Ausnahme, dass der Teilnehmer am Binärprotokoll MySQL selbst ist. MySQL spielt bei XA-Transaktionen die Rolle eines Teilnehmers, nicht eines Koordinators.
Mit anderen Worten: MySQL kann verteilte Transaktionen natürlich über die XA-Spezifikation implementieren, benötigt jedoch nur die Unterstützung einiger externer Anwendungen. Werfen wir einen Blick auf den Nutzungsprozess des XA-Modus in Seata.
Erster Blick auf ein offizielles Bild:
Wie Sie sehen, handelt es sich auch hier um eine zweistufige Einreichung:
Phase 1: Business SQL-Operationen werden im XA-Zweig, XA, durchgeführt Nach Abschluss der Verzweigung wird die XA-Vorbereitung ausgeführt und die Persistenz wird durch die Unterstützung des XA-Protokolls durch RM gewährleistet (d. h. nachfolgende Unfälle führen nicht zu einem Rollback-Fehler).
Die zweite Phase ist in zwei Situationen unterteilt: Commit oder Rollback:
Branch-Commit: Führen Sie das Commit des XA-Zweigs aus.
Branch-Rollback: Führen Sie das Rollback des XA-Zweigs aus Der Modus ist ein ernsthafter Rollback, wie wir ihn im herkömmlichen Sinne verstehen, und nicht eine umgekehrte Kompensation.
Abschließend werfen wir einen Blick auf den Saga-Modus. Dieser Modus wird selten verwendet, Sie können ihn also einfach verstehen. Der
Saga-Modus ist eine von Seata bereitgestellte Lösung für lange Transaktionen. Lange Transaktionen sollten wir jedoch in der Entwicklung vermeiden, da sie ineffizient sind und leicht zu Deadlocks führen können.
Dieser Saga-Modus ist ein bisschen wie eine Prozess-Engine. Der Entwickler zeichnet zunächst selbst eine Prozess-Engine und bezieht alle an der gesamten Transaktion beteiligten Methoden ein, und was zurückgegeben wird, ist abnormal und normal Wenn es abnormal ist, wird ein weiterer Satz von Prozessen ausgeführt. Der erste Satz ist der Ausführungsprozess für verschiedene normale Situationen. und der zweite Satz ist der Ausführungsprozess nach Auftreten einer Ausnahme, ähnlich wie folgt:
Die grünen sind normale Prozesse und die roten sind die Prozesse, die nach Auftreten einer Ausnahme zurückgesetzt werden. Rollback ist auch eine Art umgekehrte Kompensation.
Das obige ist der detaillierte Inhalt vonSo lösen Sie das Problem der verteilten Java Spring Boot-Transaktionen. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!
