Inhaltsverzeichnis
1. Probleme bei verteilten Transaktionen
2.1.3 Partitionsfehlertoleranz
2.3 Ideen zur Lösung verteilter Transaktionen
1. Probleme bei verteilten Transaktionen
1.1 Lokale Angelegenheiten
Lokale Transaktionen sind traditionelle eigenständige Transaktionen . Bei herkömmlichen Datenbanktransaktionen müssen vier Prinzipien erfüllt sein:
1.2 Verteilte Transaktionen
Verteilte Transaktionen beziehen sich auf Transaktionen, die nicht unter einem einzelnen Dienst oder einer einzelnen Datenbankarchitektur generiert werden, wie zum Beispiel:
-
Verteilte Transaktionen über Datenquellen hinweg
-
Verteilte Transaktionen über Dienste hinweg
-
Umfassende Situation
Nach der horizontalen Aufteilung der Datenbank und der vertikalen Aufteilung des Dienstes muss ein Geschäftsvorgang normalerweise mehrere Datenbanken und Dienste umfassen, um abgeschlossen zu werden. Zu den häufigsten Zahlungsfällen bei Bestellungen in der E-Commerce-Branche gehören beispielsweise die folgenden Verhaltensweisen:
-
Neue Bestellung erstellen
-
Produktbestand abziehen
-
Vom Kontostand des Benutzers abgezogener Betrag
Für den Abschluss des oben genannten Vorgangs ist Zugriff auf drei verschiedene Microservices und drei verschiedene Datenbanken erforderlich.
Die Erstellung von Bestellungen, Bestandsabzügen und Kontoabzügen ist eine lokale Transaktion in jedem Dienst und jeder Datenbank, wodurch die Originalität von ACID sichergestellt wird.
Aber.
Aber wenn wir drei Dinge als „Geschäft“ betrachten, müssen wir die Atomizität des „Geschäfts“ sicherstellen, oder alle Vorgänge müssen erfolgreich sein.
Alles ist fehlgeschlagen, teilweise erfolgreich und teilweise fehlgeschlagen. Dies ist eine Transaktion unter einem verteilten System .
Derzeit ist ACID schwer zu erfüllen, ein Problem, das durch verteilte Transaktionen gelöst werden muss.
1.3 Demonstrieren Sie Probleme mit verteilten Transaktionen
Anhand eines Falles demonstrieren wir das Problem verteilter Transaktionen:
1) Erstellen Sie eine Datenbank mit dem Namen „seata_demo“ und importieren Sie dann die in den Vorkursmaterialien bereitgestellte SQL-Datei:
2) Importieren Sie die von den Vorklassenmaterialien bereitgestellten Mikrodienste:
Die Microservice-Struktur ist wie folgt:
In:
Seata-Demo: übergeordnetes Projekt, verantwortlich für die Verwaltung von Projektabhängigkeiten
-
Kontodienst: Kontodienst, verantwortlich für die Verwaltung der Kapitalkonten der Benutzer. Bietet eine Schnittstelle zum Abziehen von Salden
-
storage-service: Lagerdienst, verantwortlich für die Verwaltung des Produktbestands. Bietet eine Schnittstelle zum Abzug von Lagerbeständen
-
order-service: Bestellservice, verantwortlich für die Verwaltung von Bestellungen. Beim Anlegen einer Bestellung müssen Account-Service und Storage-Service aufgerufen werden
3) Starten Sie Nacos und alle Microservices
4) Testen Sie die Bestellfunktion und stellen Sie eine Post-Anfrage:
Die Anfrage lautet wie folgt:
curl --location --request POST 'http://localhost:8082/order?userId=user202103032042012&commodityCode=100202003032041&count=20&money=200'Wie im Bild gezeigt:
Der Test ergab, dass bei unzureichendem Lagerbestand der Saldo, wenn er abgezogen wurde, nicht zurückgesetzt wird und ein verteiltes Transaktionsproblem auftritt.
2. Theoretische Grundlage
Die Lösung verteilter Transaktionsprobleme erfordert einige Grundkenntnisse verteilter Systeme als theoretische Anleitung.
2.1CAP-Theorem
1998 schlug Eric Brewer, Informatiker an der University of California, vor, dass verteilte Systeme über drei Indikatoren verfügen.
Konsistenz
Verfügbarkeit
Partitionstoleranz
Ihre Anfangsbuchstaben sind C, A und P.
Eric Brewer sagt, es sei unmöglich, alle drei gleichzeitig zu machen. Diese Schlussfolgerung wird CAP-Theorem genannt.
2.1.1 Konsistenz
Konsistenz: Wenn ein Benutzer auf einen beliebigen Knoten im verteilten System zugreift, müssen die erhaltenen Daten konsistent sein.
Es enthält jetzt beispielsweise zwei Knoten und die darin enthaltenen Anfangsdaten sind konsistent:
Wenn wir die Daten eines der Knoten ändern, sind die Daten der beiden unterschiedlich:
Um die Konsistenz aufrechtzuerhalten, muss eine Datensynchronisierung von Knoten01 zu Knoten02 erreicht werden:
2.1.2 Verfügbarkeit
Verfügbarkeit: Benutzer, die auf einen beliebigen fehlerfreien Knoten im Cluster zugreifen, müssen in der Lage sein, eine Antwort anstelle einer Zeitüberschreitung oder Ablehnung zu erhalten.
Wie in der Abbildung dargestellt, können Sie in einem Cluster mit drei Knoten eine zeitnahe Antwort erhalten, wenn Sie auf einen beliebigen Knoten zugreifen:
Wenn auf einige Knoten aufgrund eines Netzwerkfehlers oder aus anderen Gründen nicht zugegriffen werden kann, bedeutet dies, dass der Knoten nicht verfügbar ist:
2.1.3 Partitionsfehlertoleranz
Partition : Einige Knoten im verteilten System verlieren aufgrund eines Netzwerkfehlers oder aus anderen Gründen die Verbindung zu anderen Knoten.
Erstellen Sie eine unabhängige Partition.
Toleranz : Wenn im Cluster eine Partition auftritt, muss das gesamte System weiterhin Dienste für die Außenwelt bereitstellen.
2.1.4 Widerspruch
In einem verteilten System kann die Funktionsfähigkeit des Netzwerks zwischen den Systemen nicht zu 100 % garantiert werden. Es kommt definitiv zu Ausfällen und Dienste müssen extern geschützt werden.
Zertifikatsservice. Daher ist Partitionstoleranz unvermeidlich.
Wenn ein Knoten neue Datenänderungen empfängt, treten Probleme auf:
Wenn Sie zu diesem Zeitpunkt die Konsistenz sicherstellen möchten , müssen Sie warten, bis sich das Netzwerk erholt. Nach Abschluss der Datensynchronisierung kann der gesamte Cluster Dienste für die Außenwelt bereitstellen.
Im Sperrzustand und nicht verfügbar.
Wenn wir die Verfügbarkeit zu diesem Zeitpunkt sicherstellen möchten , können wir nicht auf die Wiederherstellung des Netzwerks warten. Dann kommt es zu Datenmangel zwischen Knoten01, Knoten02 und Knoten03.
konsistent.
Mit anderen Worten: Unter der Bedingung, dass P definitiv erscheint, kann nur eines von A und C realisiert werden.
2.2BASE-Theorie
Die BASE-Theorie ist eine Lösung für CAP und enthält drei Ideen:
-
Grundsätzlich verfügbar : Wenn in einem verteilten System ein Fehler auftritt, darf die teilweise Verfügbarkeit verloren gehen, dh die Kernverfügbarkeit ist garantiert.
-
Soft State: Innerhalb eines bestimmten Zeitraums dürfen Zwischenzustände auftreten, beispielsweise vorübergehende inkonsistente Zustände.
-
Letztendlich konsistent : Obwohl eine starke Konsistenz nicht garantiert werden kann, wird die Datenkonsistenz schließlich erreicht, nachdem der weiche Zustand endet.
2.3 Ideen zur Lösung verteilter Transaktionen
Das größte Problem verteilter Transaktionen ist die Konsistenz jeder Untertransaktion. Daher können wir aus dem CAP-Theorem und der BASE-Theorie lernen. Es gibt zwei Lösungen:
-
AP-Modus: Jede Untertransaktion wird separat ausgeführt und übermittelt, wodurch inkonsistente Ergebnisse 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 eine starke Konsistenz zu erreichen. Während die Transaktion wartet, befindet sie sich jedoch in einem schwach verfügbaren Zustand.
Aber egal um welchen Modus es sich handelt, es ist notwendig, zwischen Subsystemtransaktionen miteinander zu kommunizieren und den Transaktionsstatus zu koordinieren, das heißt, es wird ein Transaktionskoordinator (TC) benötigt :
Die Subsystemtransaktionen werden hier als Zweigtransaktionen bezeichnet ; die zugehörigen Zweigtransaktionen werden zusammen als globale Transaktionen bezeichnet .