Verteiltes Transaktions-Framework Seata
1. Was ist Seata?
- In der Microservice-Architektur sind aufgrund der Aufteilung von Datenbank- und Anwendungsdiensten mehrere DML-Operationen in einer Transaktionseinheit zu
mehreren DML-Operationen über Prozesse oder mehrere Transaktionseinheiten über Datenbanken hinweg geworden,
während herkömmliche Datenbanktransaktionen solche Probleme nicht lösen können, daher das Konzept der Verteilung Transaktionen werden eingeführt. - Der Kern verteilter Transaktionen besteht darin, das Datenkonsistenzproblem mehrerer Transaktionen über Netzwerkknoten hinweg zu lösen. In der Branche
gibt es zwei gängige Lösungen
: a. Starke Konsistenz, das heißt, alle Transaktionsteilnehmer sind entweder alle erfolgreich oder alle scheitern, der globale Transaktionskoordinator
Sie müssen den Ausführungsstatus jedes Transaktionsteilnehmers kennen und dann
entsprechend dem Status entscheiden, ob Daten übermittelt oder zurückgesetzt werden sollen!
b. Endgültige Konsistenz, auch schwache Konsistenz genannt, bedeutet, dass die Daten mehrerer Netzwerkknoten inkonsistent sein dürfen
, aber zu einem bestimmten Zeitpunkt die Datenkonsistenz erreicht wird.
Basierend auf dem CAP-Theorem können wir wissen, dass das starke Konsistenzschema Auswirkungen auf die Leistung und Verfügbarkeit der Anwendung hat. Daher wird
für Szenarien, die keine hohe Datenkonsistenz erfordern, der endgültige Konsistenzalgorithmus verwendet. - Bei der Implementierung verteilter Transaktionen können wir eine starke Konsistenz durch zweiphasiges Commit basierend auf dem XA-Protokoll implementieren
, und für eine schwache Konsistenz können wir sie basierend auf dem TCC-Transaktionsmodell, dem Zuverlässigkeitsnachrichtenmodell und anderen Schemata implementieren
. - Es gibt viele verteilte Transaktions-Frameworks für diese theoretischen Modelle auf dem Markt, und wir können diese Frameworks in Anwendungen integrieren,
um verteilte Transaktionen zu realisieren. Seata ist einer von ihnen, Alis Open-Source-Lösung für verteilte Transaktionen, die leistungsstarke und benutzerfreundliche verteilte Transaktionsdienste bietet.
Zweitens, Sitzmodul
TC (Transaktionskoordinator) – Transaktionskoordinator
Behalten Sie den Status globaler Transaktionen und Zweigstellentransaktionen bei und steuern Sie das Commit oder Rollback 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
Verwalten Sie Ressourcen für Filialtransaktionen, sprechen Sie mit TCs, um Filialtransaktionen zu registrieren und den Status von Filialtransaktionen zu melden, und sorgen Sie dafür, dass Filialtransaktionen festgeschrieben oder zurückgesetzt werden.
In Seata ist der Lebenszyklus einer verteilten Transaktion wie folgt:
TM fordert TC auf, eine globale Transaktion zu starten. TC generiert eine XID als Nummer der globalen Transaktion.
XID wird im Aufruflink von Microservices weitergegeben und stellt so sicher, dass die Untertransaktionen mehrerer Microservices miteinander verknüpft sind.
RM fordert TC auf, die lokale Transaktion als Zweigtransaktion der globalen Transaktion zu registrieren, die über die XID der globalen Transaktion zugeordnet ist.
TM fordert TC auf, XID mitzuteilen, ob die entsprechende globale Transaktion festgeschrieben oder rückgängig gemacht werden soll.
TC veranlasst RMs, ihre eigenen lokalen Transaktionen, die der XID entsprechen, festzuschreiben oder zurückzusetzen.
Seatas XA-Modell:
RM Phase Eins:
1) TM startet die globale Transaktion
2) TM ruft Zweig RM auf, RM registriert Zweig bei TC, RM führt SQL aus (aber sendet nicht!), RM meldet den Ausführungsstatus an TC
TC-Phase II:
1) TM übermittelt globale Transaktionen
2) TC zählt den Status jeder Verzweigung, und wenn alle erfolgreich sind, benachrichtigt es RM zur Übermittlung. Wenn dies fehlschlägt, wird der RM benachrichtigt, ein Rollback durchzuführen.
Seata AT-Modell:
Phase 1: TM startet globale Transaktionen, TM ruft Zweigstellen auf, RM registriert Zweigstellentransaktionen, RM zeichnet Undolog-Protokolle auf, RM schreibt Transaktionen fest und TCC zeichnet den Status jeder Zweigstelle auf
Phase zwei: TM benachrichtigt das Commit/Rollback der globalen Transaktion und TC überprüft den Transaktionsstatus jedes Zweigs. Bei Erfolg wird das Undolog-Protokoll gelöscht; wenn es fehlschlägt, wird das Undolog-Protokoll zurückgesetzt.
Dirty-Write-Problem:
Wenn eine Transaktion A SQL ausführt und festschreibt und eine andere Transaktion B ebenfalls festschreibt und die Transaktion A zu diesem Zeitpunkt ein Rollback durchführt, wird das für A aufgezeichnete Undolog-Protokoll zurückgesetzt und die Aktualisierungs- und Änderungsdatensätze von Transaktion B werden ignoriert , was zu schmutzigen Schreibfragen führt.
Lösung: Führen Sie eine globale Sperre ein und beantragen Sie eine globale Sperre, bevor Transaktion A den Preis erhöht und die DB-Sperre aufhebt. Wenn zu diesem Zeitpunkt Transaktion B den Vorgang ändert, erhält sie die globale Sperre, bevor sie den Datenbankaktualisierungsvorgang durchführt. Wenn die Die Erfassung schlägt fehl, sie kann nicht aktualisiert werden und wird fortgesetzt. Versuchen Sie es erneut, aber lassen Sie es nicht die ganze Zeit erneut versuchen, da sonst der Versuch von A, die von B belegte DB-Sperre zu erwerben, zu einem Deadlock führt. Lassen Sie es im Allgemeinen 30 Sekunden lang erneut versuchen fehlschlägt, gibt es die DB-Sperre, die es besitzt, auf und die Ausführung schlägt fehl. Zu diesem Zeitpunkt kann die A-Sperre die DB-Sperre erwerben, ein Rollback durchführen und dann die globale Sperre aufheben.
Eine weitere neue Frage stellt sich: Was ist, wenn es sich um eine weitere Transaktion handelt, die nicht unter der Leitung von Seata steht? Globale Sperre fehlgeschlagen!
XA bringt auch automatisch die Lösung:
1) Zeichnen Sie zunächst den Datensatz vor dem Update auf
2) Notieren Sie den aktualisierten Datensatz.
Der vollständige und korrekte Ausführungsprozess ist wie folgt:
1) Die Originaldaten werden mit 100 angenommen, undolog zeichnet den Wert 100 auf.
2) Transaktion A erhält die DB-Sperre und ändert die Daten auf 90, undolog zeichnet diese 90 zu diesem Zeitpunkt auf.
3) Eine Transaktion erwirbt die globale Sperre und sendet die Transaktion, um die DB-Datenbanksperre aufzuheben
4) Transaktion A wird zurückgesetzt. Bevor das Rollback 100 beträgt, wird verglichen, ob die Daten zu diesem Zeitpunkt 90 sind. Angenommen, die B-Transaktion, die nicht von Seata verwaltet wird, muss keine globale Sperre erwerben, erhält dann erfolgreich die DB-Sperre und ändert die Daten auf 80. Zu diesem Zeitpunkt vergleicht die A-Transaktion 90 (nach A-Änderung) mit 80 (B). Änderung) und gibt Roll failed zurück.
Seata TCC-Modell:
Versuchen Sie: Stellen Sie fest, ob Daten verfügbar sind, und frieren Sie die verfügbaren Daten ein, wenn sie ausreichen.
Bestätigen: Schließen Sie das Ressourcenoperationsgeschäft ab. Wenn der Versuch erfolgreich sein muss, muss die Bestätigung erfolgreich sein.
Abbrechen: Reservierte Ressourcen werden freigegeben, was als Vorgang in Try-Richtung verstanden werden kann.
Phase 1: Überprüfen Sie, ob die Ressource ausreicht, frieren Sie die Ressource ein, wenn sie ausreicht, und führen Sie die Try-Methode aus
Phase 2: Wenn die Ausführung erfolgreich ist, führen Sie die Bestätigungsmethode aus, um die eingefrorene Ressource zu löschen. Die Ausführung schlägt fehl, die Canel-Logik wird ausgeführt und eingefrorene Ressourcen werden wiederhergestellt.
Die Vor- und Nachteile der vier Transaktionstypen werden vorgestellt:
XA: Starke Konsistenz, kein Codeeinbruch, aber wenn die Transaktion nicht in der ersten Phase festgeschrieben wird, werden Ressourcen gesperrt, was zu einer geringen Leistung führt. Sie müssen sich auf die Transaktionseigenschaften der Datenbank verlassen.
AT: Standard, schwache Konsistenz, kein Code-Einbruch, einstufige Transaktionen werden direkt übermittelt, und wenn sie fehlschlagen, werden sie gemäß dem Undolog-Protokoll zurückgesetzt. Isolation führt globale Sperren ein, aber die Parallelitätswahrscheinlichkeit ist gering, daher ist die Leistung gering wird besser sein als XA.
TCC: Keine Notwendigkeit, sich auf relationale Datenbanken zu verlassen, da die Ressourcenreservierung isoliert ist. Versuchen, Bestätigen und Abbrechen müssen manuell geschrieben werden und müssen leere Suspendierungen, leere Rollbacks und idempotente Urteile berücksichtigen. Sie sind relativ kompliziert und weisen die beste Leistung auf, aber die Kosten sind zu hoch.
Seaga: Geeignet für lange Transaktionstypen, ohne zu viele Anwendungsszenarien.