Artikelverzeichnis

Verteilte Transaktion – Seata

Verteilte Transaktionen – Seata

Seata ist eine verteilte Transaktionslösung. Wir sind bestrebt , leistungsstarke und benutzerfreundliche verteilte Transaktionsdienste bereitzustellen und eine verteilte Lösung aus einer Hand für Benutzer zu schaffen. Offizielle Website-Adresse: http://seata.io/, wo Dokumente und Podcasts zahlreiche Nutzungsanweisungen und Quellcode-Analysen bieten.

Erstens das ACID-Prinzip der Transaktion

In einem verteilten System umfasst ein Unternehmen mehrere Dienste oder Datenquellen, und jeder Dienst ist eine Zweigstellentransaktion. Es muss sichergestellt werden, dass der Endstatus aller Zweigstellentransaktionen konsistent ist. Eine solche Transaktion ist eine verteilte Transaktion.

Atomizität	Alle Vorgänge in der Transaktion sind entweder alle erfolgreich oder alle fehlschlagen
Konsistenz	Um die internen Integritätsbeschränkungen und deklarativen Einschränkungen der Datenbank sicherzustellen
Isolation	Transaktionen, die auf derselben Ressource ausgeführt werden, können nicht gleichzeitig stattfinden
Beharrlichkeit	Alle an der Datenbank vorgenommenen Änderungen werden unabhängig von Fehlern dauerhaft gespeichert

Zweitens, CAP-Theorem

Verteilte Systemknoten sind über das Netzwerk verbunden, und es muss ein Partitionsproblem (P) vorliegen. Wenn eine Partition auftritt, können die Konsistenz (C) und die Verfügbarkeit (A) des Systems nicht gleichzeitig erfüllt werden.

Verteilte Systeme haben drei Metriken:

Konsistenz : Wenn ein Benutzer auf einen beliebigen Knoten im verteilten System zugreift , müssen die erhaltenen Daten konsistent sein.
Verfügbarkeit ( Verfügbarkeit ): Wenn ein Benutzer auf einen fehlerfreien Knoten im Cluster zugreift, muss er in der Lage sein, eine Antwort anstelle einer Zeitüberschreitung oder Ablehnung zu erhalten.
Partitionstoleranz ( Partitionsfehlertoleranz )
Partition: Aufgrund eines Netzwerkfehlers oder aus anderen Gründen verlieren einige Knoten im verteilten System die Verbindung zu anderen Knoten und bilden eine unabhängige Partition.
Toleranz (Fehlertoleranz): Wenn der Cluster partitioniert ist, muss das gesamte System weiterhin externe Dienste bereitstellen.

3. BASE-Theorie

1. Die BASE-Theorie ist eine Lösung für CAP, einschließlich drei Ideen:

Grundsätzlich verfügbar : Wenn ein verteiltes System ausfällt, darf es einen Teil seiner Verfügbarkeit verlieren, um sicherzustellen, dass der Kern verfügbar ist.
Soft State ( weicher Zustand ): Innerhalb eines bestimmten Zeitraums ist ein Zwischenzustand zulässig, beispielsweise ein vorübergehender inkonsistenter Zustand.
Letztendlich konsistent : Obwohl eine starke Konsistenz nicht garantiert werden kann, wird die Datenkonsistenz schließlich erreicht, nachdem der weiche Zustand endet.

2. Das größte Problem verteilter Transaktionen ist die Konsistenz jeder Untertransaktion . Daher können wir aus dem CAP-Theorem und der BASE-Theorie lernen:

AP-Modus: Jede Untertransaktion wird separat ausgeführt und übermittelt, wodurch Inkonsistenzen in den Ergebnissen möglich sind. Anschließend werden Abhilfemaßnahmen ergriffen, um die Daten wiederherzustellen und eine endgültige Konsistenz zu erreichen.
CP-Modus: Jede Untertransaktion wartet nach der Ausführung aufeinander, schreibt gleichzeitig fest und führt gleichzeitig ein Rollback durch, um einen starken Konsens zu erzielen. Während des Wartevorgangs der Transaktion befindet sie sich jedoch in einem schwach verfügbaren Zustand.

4. Verteiltes Transaktionsmodell

Um verteilte Transaktionen zu lösen, muss jedes Subsystem in der Lage sein, den Transaktionsstatus des anderen zu erkennen, um einen konsistenten Status sicherzustellen. Daher ist ein Transaktionskoordinator erforderlich, der jeden Transaktionsteilnehmer (Subsystemtransaktion) koordiniert.

1. Modell zur Lösung verteilter Transaktionen

Zweigtransaktion : Subsystemtransaktion; eine Transaktion für jedes Subsystem, das in einer verteilten Transaktion enthalten ist.
Globale Transaktion : eine Sammlung zugehöriger Filialtransaktionen; die gesamte verteilte Transaktion.

2. Die Idee , verteilte Transaktionen zu lösen

Die Idee der endgültigen Konsistenz : Jede Zweigtransaktion wird separat ausgeführt und übermittelt. Wenn eine Inkonsistenz vorliegt, finden Sie eine Möglichkeit, die Daten wiederherzustellen.
Starke Konsistenzidee : Übermitteln Sie das Geschäft nicht nach der Ausführung jeder Filialtransaktion und warten Sie auf die Ergebnisse der anderen. Dann einheitlich festschreiben oder zurücksetzen.

5. Seata-Architektur

1. Im Seata-Transaktionsmanagement gibt es drei wichtige Rollen :

TC (Transaktionskoordinator) – Transaktionskoordinator : verwaltet den Status globaler Transaktionen und Zweigstellentransaktionen und koordiniert das Festschreiben oder Zurücksetzen globaler Transaktionen.
TM (Transaction Manager) – Transaktionsmanager : Definieren Sie den Umfang einer globalen Transaktion, starten Sie eine globale Transaktion, schreiben Sie eine globale Transaktion fest oder setzen Sie sie zurück.
RM (Ressourcenmanager) – Ressourcenmanager : verwaltet Ressourcen für Zweigstellentransaktionen, kommuniziert mit TC, um Zweigstellentransaktionen zu registrieren und den Status von Zweigstellentransaktionen zu melden, und steuert Festschreibungen oder Rollbacks von Zweigstellentransaktionen.

2. Seata bietet vier verschiedene verteilte Transaktionslösungen:

XA-Modus : Phasentransaktionsmodus mit starker Konsistenz, bei dem eine bestimmte Verfügbarkeit geopfert wird und kein Geschäftseingriff erfolgt.
TCC-Modus : letztendlich konsistenter, phasenweiser Transaktionsmodus mit geschäftlichem Eingriff.
AT-Modus : Der schließlich konsistente, phasenweise Transaktionsmodus ohne geschäftliche Eingriffe ist auch der Standardmodus von Seata.
SAGA-Modus : Langer Transaktionsmodus mit Geschäftseingriff.

3. Woraus besteht der Nacos- Dienstname?

Namespace (Namespace) + Gruppe (Gruppenname) + ServiceName (Dienstname) + Cluster (Bereich).

4. Wie erhält der Seata-Client den Clusternamen tc ?

Verwenden Sie den tx-group-serviceWert des Schlüssels , um vgroupMappingihn zu finden.

Sechs, XA-Modus-Prinzip

Die XA-Spezifikation ist ein von der X/Open-Organisation definierter DTP-Standard ( Distributed Transaction Processing ). Die XA-Spezifikation beschreibt die Schnittstelle zwischen dem globalen TM und dem lokalen RM. Fast alle Mainstream-Datenbanken unterstützen die XA-Spezifikation.

6.1 Seatas XA-Modus

Die Arbeit der ersten Stufe von RM :

Registrieren Sie die Filialtransaktion bei TC
Führen Sie Branch Business SQL aus, aber senden Sie es nicht
Melden Sie den Ausführungsstatus an TC

Die Arbeit der zweiten Phase von TC :

TC erkennt den Transaktionsausführungsstatus jeder Filiale
Wenn alle erfolgreich sind, benachrichtigen Sie alle RMs, um die Transaktion festzuschreiben
Wenn ein Fehler auftritt, benachrichtigen Sie alle RMs, um die Transaktion rückgängig zu machen

Die Arbeit der zweiten Phase von RM :

Erhalten Sie TC-Anweisungen, Commit- oder Rollback-Transaktionen

6.2 Vor- und Nachteile des XA von Seata

Vorteile des XA-Modus :

Starke Konsistenz der Transaktionen unter Einhaltung des ACID-Prinzips
Häufig verwendete Datenbanken werden unterstützt, die Implementierung ist einfach und es gibt kein Eindringen in den Code

Nachteile des XA-Modus :

Da die Datenbankressourcen in der ersten Stufe gesperrt und erst nach Abschluss der zweiten Stufe freigegeben werden müssen, ist die Leistung schlecht
Sich auf relationale Datenbanken verlassen, um Transaktionen zu realisieren

6.3 Implementierung des XA-Musters

Der Starter von Seata hat die automatische Montage des XA-Modus abgeschlossen und die Implementierung ist sehr einfach. Die Schritte sind wie folgt:

Ändern Sie die Datei application.yml (jeder an der Transaktion beteiligte Mikrodienst) und aktivieren Sie den XA-Modus.
Fügen Sie die Annotation @GlobalTransactional zur Eingabemethode hinzu, die die globale Transaktion initiiert.
Starten Sie den Dienst neu und testen Sie ihn.

Sieben, AT-Modus-Prinzip

Der AT-Modus ist ebenfalls ein Transaktionsmodell mit phasenweiser Festschreibung , gleicht jedoch die lange Ressourcensperrzeit im XA-Modell aus.

Phase 1 RM -Arbeit:

Filialtransaktion registrieren
Rückgängig-Protokoll aufzeichnen (Datenschnappschuss)
Führen Sie Business SQL aus und senden Sie es ab
Transaktionsstatus melden

Die Arbeit von RM zum Zeitpunkt der Einreichung in Phase 2 :

Undo-Log löschen

Die Arbeit von RM während des Phase-2-Rollbacks :

Stellen Sie die Daten gemäß dem Undo-Log auf den Stand vor der Aktualisierung wieder her

Der größte Unterschied zwischen AT-Modus und XA-Modus :

Der XA-Modus schreibt in der ersten Stufe keine Transaktionen fest und sperrt Ressourcen; der AT-Modus schreibt direkt in der ersten Stufe fest, ohne Ressourcen zu sperren.
Der XA-Modus basiert auf dem Datenbankmechanismus, um ein Rollback zu erreichen. Der AT-Modus verwendet Daten-Snapshots, um ein Daten-Rollback zu erreichen.
Starke Konsistenz im XA-Modus; endgültige Konsistenz im AT-Modus

7.1 Dirty-Write-Problem im AT-Modus

Im Fall der Parallelität führt Transaktion eins die erste Phase von RM aus

1.1. Holen Sie sich die DB-Sperre und speichern Sie den Snapshot
1.2. Geschäftsabwicklung
1.3. Senden Sie die Transaktion und geben Sie die DB-Sperre frei

Zu diesem Zeitpunkt wird die DB-Sperre aufgehoben, Transaktion 2 erhält die DB-Sperre und führt die erste Stufe von RM aus

1.1. Holen Sie sich die DB-Sperre und speichern Sie den Snapshot
1.2. Geschäftsabwicklung
1.3. Senden Sie die Transaktion und geben Sie die DB-Sperre frei

Später wird die DB-Sperre durch Transaktion 1 erworben und die Daten werden gemäß dem Snapshot wiederhergestellt. Zu diesem Zeitpunkt wird der Snapshot wiederhergestellt, was zu einem nutzlosen Betrieb von Transaktion 2 führt, was zu Datensicherheitsproblemen führt und die Isolation nicht garantiert werden kann.

7.2 Schreibisolation im AT-Modus

Globale Sperre : TC zeichnet die Transaktion auf, die derzeit eine bestimmte Datenzeile ausführt. Diese Transaktion enthält eine globale Sperre und hat das Recht zur Ausführung.

Im Fall der Parallelität führt Transaktion eins die erste Phase von RM aus

1.1. Holen Sie sich die DB-Sperre (Datenbanksperre) und speichern Sie den Snapshot
1.2. Geschäftsabwicklung
Erwerben Sie zu diesem Zeitpunkt die globale Sperre
1.3. Senden Sie die Transaktion und geben Sie die DB-Sperre frei

Zu diesem Zeitpunkt wird die DB-Sperre aufgehoben, Transaktion 2 erhält die DB-Sperre und führt die erste Stufe von RM aus

1.1. Holen Sie sich die DB-Sperre und speichern Sie den Snapshot
1.2. Geschäftsabwicklung
Zu diesem Zeitpunkt wird die globale Sperre erworben, aber da Transaktion 1 erworben und wiederholt wurde, beträgt der Standardwert 30 Mal
mit einem Intervall von 10 Millisekunden
1.4. Task-Timeout, Rollback und Freigabe der DB-Sperre

Zu diesem Zeitpunkt das Geschäft

Warten Sie auf die DB-Sperre
2.1. Erhalten Sie die DB-Sperr- und Wiederherstellungsdaten basierend auf dem Snapshot
Geben Sie die globale Sperre frei

Da die Wartezeit der DB-Sperre länger ist als die der globalen Sperre, kann Transaktion 1 auf das Timeout der Transaktion 2-Aufgabe warten, ein Rollback durchführen und die DB-Sperre aufheben, es gibt jedoch immer noch Einschränkungen. Die globale Sperre kann nur funktionieren Gemeinsam über die Transaktionen von Seata, nicht über die Verwaltung globaler Transaktionen von Seata. Sie können auch die Felder von Seata ändern.

Lösung

1.1. Transaktion 1 erwirbt die DB-Sperre und speichert den Snapshot -> before-image
1.2. Transaktion 1 führt Geschäftsvorgänge aus -> Nachbild (nach der Ausführung einen Snapshot erstellen)
In diesem Extremfall ändert die globale Nicht-Seata-Verwaltungstransaktion die Felder von Seata, schreibt die Transaktion fest und gibt die DB-Sperre frei
Zu diesem Zeitpunkt erhält Transaktion 1 die DB-Sperre in 2.1., stellt die Daten gemäß dem Snapshot wieder her, vergleicht, ob die Felddaten der Datenbank zu diesem Zeitpunkt geändert wurden, vergleicht sie mit dem Nachbild und gibt dann das Globale frei sperren.
2.2. Auffälligkeiten aufzeichnen, Warnungen senden und manuell eingreifen

7.3 Vor- und Nachteile des AT-Modus

Vorteile des AT-Modus :

Schließen Sie die direkte Übermittlung von Transaktionen in einem Schritt ab, geben Sie Datenbankressourcen frei und erzielen Sie eine bessere Leistung
Verwenden Sie globale Sperren, um eine Lese-/Schreibisolation zu erreichen
Kein Eindringen in den Code, das Framework führt Rollback und Commit automatisch durch

Nachteile des AT-Modus :

Der weiche Zustand zwischen den beiden Phasen gehört zur Endkonsistenz
Die Snapshot-Funktion des Frameworks wirkt sich auf die Leistung aus, ist jedoch viel besser als der XA-Modus

Acht, TCC-Modus-Prinzip

Der TCC-Modus ist dem AT-Modus sehr ähnlich und jede Stufe stellt eine unabhängige Transaktion dar. Der Unterschied besteht darin, dass TCC die Datenwiederherstellung durch manuelle Codierung implementiert . Drei Methoden müssen implementiert werden:

Versuchen Sie: Ressourcenerkennung und -reservierung
Bestätigen: Schließen Sie das Ressourcenoperationsgeschäft ab; es ist erforderlich, dass der Versuch erfolgreich und die Bestätigung erfolgreich sein muss
Abbrechen: Reservierte Ressourcen werden freigegeben, was als umgekehrter Vorgang von try verstanden werden kann

8.1 Beispiel für den TCC-Modus

Ein Unternehmen, das Benutzerguthaben abzieht. Unter der Annahme, dass der ursprüngliche Saldo von Konto A 100 beträgt, müssen vom Saldo 30 Yuan abgezogen werden.

Phase 1 (Versuchen): Überprüfen Sie, ob der Restbetrag ausreicht. Wenn er ausreicht, wird der eingefrorene Betrag um 30 Yuan erhöht und der verfügbare Restbetrag wird um 30 Yuan abgezogen
Phase 2: Wenn Sie absenden (bestätigen) möchten, wird der eingefrorene Betrag um 30 abgezogen
Phase 2: Wenn Sie einen Rollback durchführen (Abbrechen) möchten, wird der eingefrorene Betrag um 30 abgezogen und das verfügbare Guthaben um 30 erhöht

8.2 Vor- und Nachteile des TCC-Modus

Vorteile von TCCs :

Schließen Sie die direkte Festschreibungstransaktion in einer Phase ab, geben Sie Datenbankressourcen frei und erzielen Sie eine gute Leistung
Im Vergleich zum AT-Modell ist es nicht erforderlich, Snapshots zu generieren, keine globalen Sperren zu verwenden und die Leistung ist am stärksten
Verlässt sich nicht auf Datenbanktransaktionen, sondern auf Kompensationsvorgänge, die für nicht-transaktionale Datenbanken verwendet werden können

Nachteile von TCC :

Es liegt ein Codeeinbruch vor, und das manuelle Schreiben von Try-, Bestätigungs- und Abbruchschnittstellen ist zu mühsam
Weicher Zustand, Transaktionen sind schließlich konsistent
Es ist notwendig, den Fehler von Bestätigen und Abbrechen zu berücksichtigen und eine idempotente Verarbeitung durchzuführen

8.3 Leeres Rollback und Dienstunterbrechung von TCC

Leeres Rollback : Wenn die Versuchsphase einer Verzweigungstransaktion blockiert ist, kann dies zu einer Zeitüberschreitung der globalen Transaktion führen und den Abbruchvorgang der zweiten Phase auslösen. Der Abbruchvorgang wird ausgeführt, bevor der Versuchsvorgang ausgeführt wird, und der Abbruch kann zu diesem Zeitpunkt nicht rückgängig gemacht werden.
Geschäftsaussetzung : Wenn Sie bei einem Unternehmen, das leer zurückgesetzt wurde, den Versuch in Zukunft weiterhin ausführen, ist eine Bestätigung oder Stornierung nie mehr möglich.
Der Try-Vorgang nach einem leeren Rollback sollte verhindert werden, um eine Unterbrechung zu vermeiden. Um den Try-Vorgang auszuführen, muss zunächst festgestellt werden, ob ein Rollback stattgefunden hat, und er wird beendet, wenn er auftritt. Um den Abbruchvorgang auszuführen, ist dies ebenfalls erforderlich um zunächst festzustellen, ob die Try-Operation ausgeführt wurde.

ps: Der TCC-Modus ähnelt dem AT-Modus. Der AT-Modus des Datenquellen-Proxys in der YML-Datei muss nicht geändert werden. Sie müssen nur drei Methoden schreiben und implementieren, um den TCC-Modus zu implementieren.

Neun, Saga-Modus

Der Saga-Modus ist eine von SEATA bereitgestellte Lösung für lange Transaktionen . Es ist außerdem in zwei Phasen unterteilt:

Phase 1: Lokale Transaktionen direkt einreichen
Phase 2: Wenn es gelingt, unternehmen Sie nichts; wenn es fehlschlägt, wird es einen Rückzieher machen, indem es Kompensationsgeschäfte schreibt

9.1 Vor- und Nachteile des Saga-Modus

Vorteile des Saga-Modus

Transaktionsteilnehmer können asynchrone Aufrufe basierend auf ereignisgesteuertem, hohem Durchsatz implementieren
Senden Sie Transaktionen direkt in einem Schritt, keine Sperren, gute Leistung
Es ist einfach zu implementieren, ohne die drei Stufen in TCC schreiben zu müssen

Nachteile des Saga-Modus

Die Dauer des Soft State ist ungewiss und die Aktualität ist schlecht
Keine Sperren, keine Transaktionsisolation, schmutzige Schreibvorgänge

10. Vergleich von vier Modi

	SCHAH	BEI	TCC	SAGA
Konsistenz	starke Konsistenz	Schwache Konsistenz	Schwache Konsistenz	schließlich konsistent
Isolation	völlig isoliert	Basierend auf globaler Sperrisolation	Isolation basierend auf Ressourcenreservierung	keine Isolation
Code-Hacking	keiner	keiner	Ja, es gibt drei Schnittstellen zum Schreiben	Ja, um Staatsmaschinen- und Vergütungsgeschäfte zu schreiben
Leistung	Unterschied	Gut	sehr gut	sehr gut
Szenen	Dienste mit hohen Anforderungen an Konsistenz und Isolation	Die meisten verteilten Transaktionsszenarien, die auf relationalen Datenbanken basieren, können dies tun	Transaktionen mit hohen Leistungsanforderungen. Es gibt Transaktionen, an denen die nicht relationale Datenbank teilnimmt.	Der Geschäftsprozess ist langwierig und hat mehrere Teilnehmer, darunter andere Unternehmen oder Legacy-Systemdienste, die die drei vom TCC-Modell geforderten Schnittstellen nicht bereitstellen können

->微服务技术栈高级篇--分布式事务--Seata课程视频

Fortgeschrittener Tag 2-01 – Theoretische Grundlagen verteilter Transaktionen_哔哩哔哩_bilibili

<-

记录每一个学习瞬间

Verteilte Transaktion – Seata