Vergleichszusammenfassung der vier Modi von Seata | Spring Cloud 59

I. Einleitung

Durch die folgende Kapitelreihe:

docker-compose implementiert die Hochverfügbarkeitsbereitstellung von Seata Server | Spring Cloud 51

Seata AT-Modus-Theoriestudie, Transaktionsisolation und teilweise Quellcodeanalyse | Spring Cloud 52

Spring Boot integriert Seata mit einem Beispiel für verteilte Transaktionen im AT-Modus | Spring Cloud 53

Lernen, Verwendung und Vorsichtsmaßnahmen für die Theorie des Seata XA-Modus | Spring Cloud54

Lernen der Theorie des Seata TCC-Modus, Anwendungsbeispielkonstruktion auf Produktionsebene und Vorsichtsmaßnahmen | Spring Cloud55

Lösen Sie die Probleme von Idempotenz, Suspension und leerem Rollback im Seata TCC-Modus | Spring Cloud56

Lernen der Theorie des Seata Saga-Modus, Beispielkonstruktion und Vorsichtsmaßnahmen für die Verwendung auf Produktionsebene (1) | Spring Cloud57

Lernen der Theorie des Seata Saga-Modus, Beispielkonstruktion und Vorsichtsmaßnahmen für die Verwendung auf Produktionsebene (2) | Spring Cloud58

Wir verfügen über ein tiefgreifendes Verständnis der Theorie und Verwendung der SeataModi AT, XA, TCC, und Transaktion und vergleichen und fassen die vier Modi der heutigen verteilten Grundtheorie und zusammen.SagaSeata

Zweitens: Affären

Ein einfaches Verständnis einer Transaktion ist eine Programmausführungseinheit (), die verschiedene Daten in der Datenbank aktualisiert unit. Genau genommen muss eine Transaktion Atomizität, Konsistenz, Isolation und Persistenz aufweisen, die als bezeichnet werden ACID.

• Atomarität ( Atomicity): Alle Vorgänge innerhalb einer Transaktion werden entweder ausgeführt oder nicht ausgeführt.

• Konsistenz ( Consistency): Konsistenz bedeutet, dass die Transaktion die Datenbank von einem konsistenten Zustand in einen anderen ändern muss, dh die Ergebnisse vor und nach der Datenbankverarbeitung sollten mit den Ergebnissen nach der Ausführung gemäß den Geschäftsregeln übereinstimmen.

• Isolation ( Isolation): Bezieht sich auf die Tatsache, dass sich mehrere Transaktionen nicht gegenseitig stören, wenn sie gleichzeitig ausgeführt werden.

• Persistenz ( Durability): Bezieht sich auf die Tatsache, dass die Daten nach Abschluss einer Transaktion für immer gespeichert werden und andere nachfolgende Vorgänge oder Fehler keinen Einfluss auf das Ergebnis der Transaktion haben.

3. Verteilte Transaktionen

Wie der Name schon sagt, dienen verteilte Transaktionen dazu, Transaktionen in verteilten Systemen zu implementieren, die aus mehreren lokalen Transaktionen bestehen.

Die Hauptursache für die Verwendung verteilter Transaktionen ist die hohe Parallelität. Wenn ein Server zu ausgelastet ist, müssen mehrere Server hinzugefügt werden, um auf Anforderungen reagieren zu können. Zu diesem Zeitpunkt tritt ein Problem auf, das heißt, es gibt nur eine Kopie der Daten. So stellen Sie sicher, dass in einer verteilten Umgebung nach jeder Transaktion die Daten korrekt sind, z. B. Inventarservice, Bestellservice und Zahlung Dienst. Sie werden separat bereitgestellt. Zu diesem Zeitpunkt müssen alle drei Dienste nach Abschluss des Kaufs entsprechende Vorgänge abschließen, entweder gemeinsam fehlschlagen oder gemeinsam erfolgreich sein. Dies führt zu dem Problem, verteilte Transaktionen zu lösen.

4. CAP-Theorie

In einem verteilten System können die drei Elemente Konsistenz ( Consistency), Verfügbarkeit ( Availability) und Partitionstoleranz ( ) höchstens zwei Punkte gleichzeitig erreichen, und es ist unmöglich, alle drei zu berücksichtigen.Partition tolerance

• Konsistenz ( Consistency): Ob alle Datensicherungen in einem verteilten System gleichzeitig den gleichen Wert haben. (entspricht dem Zugriff aller Knoten auf dieselbe neueste Datenkopie)

• Verfügbarkeit ( Availability): Gibt an, ob der Cluster als Ganzes nach dem Ausfall einiger Knoten im Cluster noch auf die Lese- und Schreibanforderungen des Clients reagieren kann. (hohe Verfügbarkeit für Datenaktualisierungen)

• Partitionstoleranz ( PartitionToleranz): In Bezug auf die praktische Wirkung entspricht die Partition der zeitlichen Begrenzung der Kommunikation. Wenn das System die Datenkonsistenz nicht innerhalb des Zeitlimits erreichen kann, bedeutet dies, dass eine Partitionierung aufgetreten ist und für den aktuellen Vorgang eine Auswahl zwischen C und A getroffen werden muss

Der überlappende Teil in der Abbildung ist der Kompromiss, der in einer verteilten Umgebung eingegangen werden muss: entweder CP, oder AP, oder CA, aber er existiert nicht CAP.

CP: Opfern Sie die Benutzerfreundlichkeit. Das Replikationssynchronisationsprotokoll verwendet im Allgemeinen ein striktes Quorumprotokoll ( Paxos, Raft, ZAB) oder 2PCein Protokoll. CPSystemtypen sind MongoDB, HBase, Zookeeper, Redisusw.ElasticSearch

AP: Konstanz opfern. Das Replikationssynchronisierungsprotokoll verwendet im Allgemeinen ein nicht striktes Quorumprotokoll. APSystemtypen sind Couch DB, Cassandra, Amazon Dynamousw.

CA: Abgesehen RDBMSdavon Oraclegibt MySQLes unter den verteilten Systemen, die behaupten, systematisch zu sein CA, Google Spannerund Ali OceanBase.

F: Warum können in einem verteilten System nicht sowohl Konsistenz als auch Verfügbarkeit garantiert werden?

Antwort: Zunächst einmal gibt es eine Prämisse: Für verteilte Systeme ist Partitionsfehlertoleranz die grundlegendste Anforderung, sodass wir beim Entwurf eines verteilten Systems grundsätzlich nur zwischen Konsistenz ( C) und Verfügbarkeit ( ) wählen können.A

Wenn die Konsistenz gewährleistet ist ( C): Für den Knoten N1und muss N2beim Schreiben von Daten N1in , N2der Vorgang darauf ausgesetzt werden, und erst wenn N1die Synchronisierungsdaten eintreffen , N2können die Lese- N2und Schreibanforderungen gestellt und N2die Anforderung währenddessen vom Client übermittelt werden Der angehaltene Vorgang wird als „Empfang fehlgeschlagen“ oder „Zeitüberschreitung“ angezeigt. Offensichtlich steht dies im Widerspruch zur Benutzerfreundlichkeit.

Wenn die Verfügbarkeit gewährleistet ist ( A): Dann N2können die Lese- und Schreibvorgänge nicht ausgesetzt werden, N1wenn jedoch gleichzeitig Daten geschrieben werden, verstößt dies gegen die Konsistenzanforderung.

CAPACIDDie Summe in und Aist Cganz anders:

• CDer Unterschied:

  • ACIDBei der Konsistenz geht es um Datenbankregeln, und die Datenbank wechselt immer von einem konsistenten Zustand in einen anderen konsistenten Zustand.

  • CAPKonsistenz besteht darin, Daten zwischen verteilten Multiservern zu replizieren, sodass diese Server über dieselben Daten verfügen. Aufgrund von Netzwerkgeschwindigkeitsbeschränkungen ist die für diese Replikation auf verschiedenen Servern benötigte Zeit nicht festgelegt. Cluster sehen unterschiedliche Knoten, indem sie Clients organisieren. Behalten Sie eine logische Ansicht bei Daten, die nicht im Internet synchronisiert wurden, was ein Konzept der Konsistenz in der verteilten Domäne darstellt;

• ADer Unterschied:

  • ACIDbezieht sich Aauf Atomizität ( Atomicity), was bedeutet, dass eine Transaktion als unteilbare Mindestarbeitseinheit betrachtet wird und alle Vorgänge in der Transaktion entweder erfolgreich festgeschrieben oder nach einem Fehler zurückgesetzt werden;

  • CAPbezieht sich Aauf Verfügbarkeit ( Availability), die sich darauf bezieht, ob der Cluster als Ganzes auf die Lese- und Schreibanforderungen des Clients reagieren kann, nachdem einige Knoten im Cluster ausgefallen sind;

Fünftens: BASE-Theorie

BASEist ein Akronym für Basically Available(grundsätzlich verfügbar), Soft state(weicher Zustand) und Eventually consistent(eventuell konsistent).

In einem verteilten System CAPist die Theorie das leitende Denken, und BASEdie Theorie ist eine Erweiterung CAPder Theorie , die das Ergebnis eines Kompromisses zwischen Konsistenz und Verfügbarkeit im System ist. Die Kernidee lautet: Auch wenn es keine starke Konsistenz geben kann Wenn dies erreicht ist, kann jede Anwendung entsprechend ihren eigenen Geschäftsmerkmalen geeignete Methoden anwenden, um dem System eine endgültige Konsistenz zu verleihen.APCAP

• Grundlegende Verfügbarkeit ( Basically Available): Dies bedeutet, dass ein verteiltes System bei einem Ausfall einen Teil der Verfügbarkeit verlieren darf, um sicherzustellen, dass der Kern verfügbar ist.

• Flexibler Zustand ( Soft state）: bezieht sich darauf, dass das System einen Zwischenzustand haben kann, und es wird davon ausgegangen, dass der Zwischenzustand die Gesamtverfügbarkeit des Systems nicht beeinträchtigt. Beispielsweise ist die Verzögerung, die die Replikatsynchronisation zwischen verschiedenen Knoten ermöglicht, die Verkörperung von Flexibilität Zustand.

• Endgültige Konsistenz ( Eventually consistent): Dies bedeutet, dass alle Kopien im System nach einer bestimmten Zeitspanne endlich einen konsistenten Zustand erreichen können. Daher besteht das Wesen der endgültigen Konsistenz darin, dass das System sicherstellen muss, dass die endgültigen Daten konsistent sein können, und nicht die starke Konsistenz der Systemdaten in Echtzeit sicherstellen muss.

6. Transaktionskonsistenz

• Starke Konsistenz: Nachdem bestimmte Daten im System erfolgreich aktualisiert wurden, können nachfolgende Zugriffe den aktualisierten Wert sehen.

• Schwache Konsistenz: Nachdem bestimmte Daten im System aktualisiert wurden, erhält der nachfolgende Zugriff möglicherweise den aktualisierten Wert oder den Wert vor der Änderung.

• Endgültige Konsistenz: Bestimmte Daten im System werden aktualisiert, und nach einer gewissen Zeit sind alle Zugriffe endgültig aktualisierte Werte.

Starre Angelegenheiten: Befolgen Sie ACIDdas Prinzip, starke Konsistenz.

Flexible Transaktionen: Befolgen Sie BASEdie Theorie und letztendliche Konsistenz.

七、Set

SeataEs handelt sich um eine verteilte Transaktionslösung, die Ant Financial und Alibaba im Januar 2019 gemeinsam als Open Source bereitgestellt haben. 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.

7.1 Architektur

SeataIm Transaktionsmanagement gibt es drei wichtige Rollen:

• TC( Transaction Coordinator) – Transaktionskoordinator: verwaltet den Status globaler Transaktionen und Zweigstellentransaktionen und koordiniert das Festschreiben oder Zurücksetzen globaler Transaktionen.

• TM( Transaction Manager) – Transaktionsmanager: Definiert den Umfang einer globalen Transaktion, startet eine globale Transaktion, schreibt eine globale Transaktion fest oder setzt sie zurück.

• RM( Resource Manager) – Ressourcenmanager: Verwalten Sie Ressourcen für Filialtransaktionen, sprechen Sie mit TC, um Filialtransaktionen zu registrieren und den Status von Filialtransaktionen zu melden, und steuern Sie Filialtransaktionen zum Festschreiben oder Zurücksetzen

SeataBasierend auf der oben genannten Architektur werden vier verschiedene verteilte Transaktionslösungen bereitgestellt:

• XAModus: Phasentransaktionsmodus mit starker Konsistenz, bei dem eine bestimmte Verfügbarkeit geopfert wird und kein Geschäftseingriff erfolgt

• TCCModus: Eventuell konsistenter, phasenweiser Transaktionsmodus mit Geschäftseingriff

• ATModus: letztendlich konsistenter, phasenweiser Transaktionsmodus, kein Eingriff in das Geschäft, auch der Standardmodus von Seata

• SAGAModus: Langer Transaktionsmodus mit Geschäftseingriff

7.2 XA-Modus

7.2.1 Gesamtmechanismus

Im SeataRahmen verteilter Transaktionen definiert durch , ein TransaktionsmodusXA , der die Unterstützung von Transaktionsressourcen (Datenbanken, Nachrichtendienste usw.) für XAdas Protokoll nutzt, um Zweigtransaktionen mit dem Mechanismus des Protokolls zu verwalten .

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

③ Ausführungsstatus an TC melden

Die Arbeit der zweiten Phase von TC:

• TC erkennt den Transaktionsausführungsstatus jeder Filiale

  • a. Wenn alle erfolgreich sind, benachrichtigen Sie alle RMs, die Transaktion festzuschreiben
  • b. Wenn ein Fehler auftritt, benachrichtigen Sie alle RMs, um die Transaktion zurückzusetzen

Die Arbeit der zweiten Phase von RM:

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

7.2.2 Vor- und Nachteile

• Welche Vorteile bietet der XA-Modus?

  • Die starke Konsistenz der Transaktionen entspricht dem ACID-Prinzip.

  • Häufig verwendete Datenbanken werden unterstützt, die Implementierung ist einfach und es gibt kein Eindringen in den Code

• Welche Nachteile hat der 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

7.3 AT-Modus

7.3.1 Gesamtmechanismus

ATDas Muster ist eine Weiterentwicklung des Zwei-Phasen-Commit-Protokolls (letztendlich konsistentes, phasenweises Transaktionsmuster). Es gleicht XAden Fehler aus, dass die Ressourcensperrzeit im Modus zu lang ist.

Phase-1- RMArbeit:

• Filialtransaktion registrieren

• Datensatz undo-log(Datenschnappschuss)

• Geschäfte ausführen sqlund einreichen

• Transaktionsstatus melden

RMArbeiten Sie an der Commit-Phase 2 :

• undo-logeinfach löschen

RMArbeit während des Phase-2-Rollbacks :

• Laut undo-logWiederherstellung der Daten vor dem Update

7.3.2 Der Unterschied zwischen AT und XA

• XAIn der ersten Phase des Modus werden Transaktionen nicht festgeschrieben und Ressourcen werden gesperrt; ATin der ersten Phase des Modus werden Ressourcen nicht gesperrt.

• XAMuster basieren auf Datenbankmechanismen für das Rollback; ATMuster nutzen Daten-Snapshots für das Daten-Rollback.

• XASchemata sind stark konsistent; ATSchemata sind schließlich konsistent.

7.4 TCC-Modus

7.4.1 Gesamtmechanismus

Das Ganze ist ein zweiphasiges Commit- Modell. Eine globale Transaktion besteht aus mehreren Zweigtransaktionen, und die Zweigtransaktionen müssen die Anforderungen des zweiphasigen Festschreibungsmodells erfüllen , d. h. jede Zweigtransaktion muss über ihre eigenen verfügen:

• TryVerhalten im ersten Stadium
• zweite Stufe Confirmoder CancelVerhalten

An dem obigen Prozess sind insgesamt drei Methoden beteiligt: Try​​Diese drei Methoden sind vollständig benutzerdefinierte Methoden und müssen von uns selbst implementiert werden. Im Vergleich zum Transaktionsmodus ist dieser Modus nicht von der Transaktionsunterstützung der zugrunde liegenden Datenbank abhängig.ConfirmCancelATTCC

7.4.2 Vor- und Nachteile

TCCWas bewirkt jede Phase des Musters?

• Try: Ressourcenprüfung und -reservierung

• Confirm: Geschäftsausführung und -vorlage

• Cancel: Freigabe reservierter Ressourcen

TCCWas sind die Vorteile?

• 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

TCCWas sind die Nachteile?

• 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, Confirmden CancelFehler der Summe zu berücksichtigen und eine idempotente Verarbeitung durchzuführen

7.5 Saga-Modus

7.5.1 Gesamtmechanismus

SagaDer Modus Seatastellt eine langfristige Transaktionslösung bereit. In Sagadiesem Modus übermittelt jeder Teilnehmer am Geschäftsprozess eine lokale Transaktion. Wenn ein bestimmter Teilnehmer ausfällt, werden die vorherigen erfolgreichen Teilnehmer entschädigt. Der Vorwärtsdienst der ersten Stufe und der der zweiten Stufe Vergütungsdienstleistungen werden durch die Geschäftsentwicklung umgesetzt.

Theoretische Grundlage: Hector & Kenneth veröffentlichten die Arbeit Sagas (1987)

7.5.2 Vor- und Nachteile

• Anwendbare Szene:
  • Langer Geschäftsprozess und viele Geschäftsprozesse
  • Zu den Teilnehmern gehören andere Unternehmen oder Altsystemdienste, die die drei vom TCC-Modell geforderten Schnittstellen nicht bereitstellen können
• Vorteil:
  • Führen Sie lokale Transaktionen in einer Phase durch, ohne Sperren und mit hoher Leistung
  • Ereignisgesteuerte Architektur, Teilnehmer können asynchron ausführen, hoher Durchsatz
  • Kompensationsleistungen sind einfach umzusetzen
• Mangel:
  • Die Isolation ist nicht gewährleistet

8. Vergleich der vier Modi von Seata

-	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 und Transaktionen mit nicht relationalen Daten	Der Geschäftsprozess ist langwierig und es gibt viele Geschäftsprozesse. Zu den Teilnehmern gehören andere Unternehmen oder Legacy-Systemdienste, die die TCCdrei vom Modell geforderten Schnittstellen nicht bereitstellen können