Der Inhalt dieses Artikels ist eine detaillierte Erläuterung der verteilten Transaktionen mit Bildern und Texten. Er hat einen gewissen Referenzwert. Ich hoffe, er wird für Sie hilfreich sein.
Dieses Mal habe ich mir durch die Verwendung des Frameworks für verteilte Transaktionen etwas Wissen über verteilte Transaktionen angeeignet, daher werden wir in diesem Artikel über verteilte Transaktionen sprechen. Sehen wir uns zunächst an, was eine Transaktion ist.
Transaktionen
Was ist eine Transaktion? Dies ist eine Back-End-Entwicklung, solange in der täglichen Entwicklung eine Interaktion mit der Datenbank stattfindet. Ziehen Sie nun eine Erklärung aus dem Wiki aus, um zu erklären, was eine Transaktion ist.
ist eine logische Einheit im Ausführungsprozess des Datenbankverwaltungssystems, die aus einer begrenzten Abfolge von Datenbankoperationen besteht.
Das Datenbanksystem weist Transaktionsmerkmale auf, was ein wichtiges Merkmal ist, das es von anderen unterscheidet das Dateisystem. Wenn in einem herkömmlichen Dateisystem eine Datei geschrieben wird und das Betriebssystem plötzlich abstürzt, kann die Datei beschädigt werden. Das Datenbanksystem führt Transaktionsfunktionen ein, um sicherzustellen, dass die Datenbank von einem Zustand in einen anderen wechselt. Beim Einreichen Ihrer Arbeit können Sie sicher sein, dass entweder alle Änderungen gespeichert werden oder keine.
Normalerweise besteht eine Transaktion aus mehreren Lese- und Schreibvorgängen.
Transaktionen weisen vier grundlegende Merkmale auf, die allgemein als ACID bekannt sind.
A (Atomizität): Atomizität. Die Transaktion wird als Ganzes behandelt. Entweder sind alle Anweisungen erfolgreich oder alle schlagen fehl. Es kann nicht vorkommen, dass einige Anweisungen erfolgreich sind und andere fehlschlagen.
C (Consistenc): Konsistenz. Wenn sich der Zustand der Datenbank von einem Zustand in einen anderen ändert, bleiben die Datenbankintegritätsbeschränkungen vor Beginn und nach Ende der Transaktion unverändert. Was bedeutet Datenbankintegritätseinschränkung? Wenn beispielsweise das Namensfeld einer Tabelle eine eindeutige Einschränkung darstellt und das Namensfeld nach dem Festschreiben oder Zurücksetzen der Transaktion nicht mehr eindeutig ist, wird dadurch die Integritätsbeschränkung der Datenbank zerstört.
I (Isolation): Isolation. Mehrere gleichzeitige Transaktionen werden ausgeführt, ohne sich gegenseitig zu beeinflussen.
D (Haltbarkeit): Haltbarkeit. Nachdem die Transaktion festgeschrieben wurde, können ihre Änderungen an der Datenbank dauerhaft in der Datenbank gespeichert werden. Daher erfordert diese Funktion, dass das Datenbanksystem in der Lage ist, Daten zu übermitteln, ohne sie zu verlieren, wenn sie bei einem Absturz wiederhergestellt werden müssen.
Daher verfügte unser System in der Anfangszeit nur über eine Datenquelle. Zu diesem Zeitpunkt konnten wir uns auf Datenbanksystemtransaktionen verlassen, um die Korrektheit des Geschäfts sicherzustellen.
Da das Unternehmen jedoch weiter wächst, kann eine einzelne Tabelle unseres Unternehmens zig Millionen Daten enthalten. Bei der Verwendung einer anderen Datenbankinstanz kann es zu Leistungsproblemen kommen. Zu diesem Zeitpunkt werden wir Unterdatenbanken und Tabellen betrachten. Dies kann jedoch dazu führen, dass eine einzelne Anwendung eine Verbindung zu mehreren Datenquellen herstellt. Siehe das Beispiel unten.
Im oben gezeigten Kaufprozess befinden sich die Händler-Saldotabelle und die Benutzer-Saldotabelle in zwei separaten Datenbankinstanzen, sodass separate Transaktionen sichergestellt werden können Abzüge Der Abzug des Händlerguthabens oder Benutzerguthabens ist entweder erfolgreich oder schlägt fehl. Wir können jedoch nicht garantieren, dass beide Transaktionen gleichzeitig erfolgreich sind oder scheitern.
Da das System immer größer wird, entscheiden wir uns dafür, die Systemanwendung in mehrere Mikrodienste aufzuteilen, sodass eine einzelne Anwendung nur eine Datenquelle betreiben kann. Zu diesem Zeitpunkt werden wir auf eine Situation stoßen, in der ein Geschäftsaufruf mehrere Anwendungen aufruft und jede Anwendung die Datenquelle unabhängig betreibt, wie unten gezeigt.
In diesem Fall können wir nicht garantieren, dass alle Anrufe erfolgreich sind.
Aus dem obigen Beispiel können wir ersehen, dass mit der Geschäftsentwicklung herkömmliche Einzeltransaktionen die Anforderungen unseres Unternehmens derzeit nicht mehr erfüllen können.
Auszug aus der Wiki-Erklärung.
Eine verteilte Transaktion ist eine Datenbanktransaktion, an der zwei oder mehr Netzwerkhosts beteiligt sind.
Lassen Sie uns zunächst über einige theoretische Grundlagen für die Implementierung verteilter Transaktionen sprechen.
CAP-Theorem. In einem verteilten System (einer Ansammlung von Knoten, die miteinander verbunden sind und Daten teilen) können bei Lese- und Schreibvorgängen nur Konsistenz, Verfügbarkeit und Partitionstoleranz garantiert werden. Von den beiden muss der andere geopfert werden .
Auszug aus Geek Time Learning Architecture aus 0 Kapitel 22 Erklärung
Obwohl die theoretische Definition von CAP darin besteht, dass nur zwei der drei Elemente verwendet werden können, werden wir bei Betrachtung einer verteilten Umgebung feststellen, dass das P-Element (Partitionstoleranz) aufgrund des Netzwerks selbst ausgewählt werden muss kann nicht 100 % erreichen Es ist zuverlässig und kann ausfallen, daher ist die Partitionierung ein unvermeidliches Phänomen. Wenn wir CA wählen und P aufgeben, dann erfolgt die Partitionierung, um sicherzustellen C, das System muss das Schreiben verbieten, wenn eine Schreibanforderung vorliegt, gibt das System einen Fehler zurück (z. B. lässt das aktuelle System kein Schreiben zu), was zu einem Konflikt mit A führt, da A erfordert, dass kein Fehler zurückgegeben wird. und keine Auszeit. Daher ist es theoretisch unmöglich, eine CA-Architektur für verteilte Systeme zu wählen, sondern nur eine CP- oder AP-Architektur
BASE-Theorie, die die Abkürzung der folgenden drei Wörter ist.
Grundsätzlich verfügbar: Wenn in einem verteilten System ein Fehler auftritt, dürfen einige verfügbare Funktionen verloren gehen, um sicherzustellen, dass Kernfunktionen verfügbar sind.
Soft State: Ermöglicht die Existenz von Zwischenzuständen im System. Dieser Zustand hat keinen Einfluss auf die Systemverfügbarkeit. Dies bezieht sich auf Inkonsistenzen im CAP.
Endgültige Konsistenz: Eventuelle Konsistenz bedeutet, dass nach einer gewissen Zeit alle Knotendaten konsistent sind.
BASE ist eine Ergänzung zum AP-System in CAP. Verwenden Sie Soft State und Eventual Consistency in BASE, um verzögerte Konsistenz sicherzustellen. BASE und ACID sind gegensätzliche Modelle, aber BASE opfert diese starke Konsistenz, sodass Daten in kurzer Zeit inkonsistent und letztendlich konsistent sind.
Als nächstes werfen wir einen Blick auf die Implementierungsmöglichkeiten für verteilte Transaktionen.
Basierend auf der Datenbankressourcenebene
2PC-Zweiphasen-Commit-Protokoll
3PC-Dreiphasen-Einreichungsprotokoll
Basierend auf Geschäftsebene
TCC
Basierend auf der Implementierungslösung auf Datenbankressourcenebene müssen wir eine Rolle haben, um den Status jeder Transaktion zu verwalten, da es mehrere Transaktionen gibt. Wir nennen diese Rolle Koordinator und die Transaktionsteilnehmer werden Teilnehmer genannt. Teilnehmer und Koordinatoren basieren im Allgemeinen auf einem bestimmten Protokoll. Das bekannteste ist derzeit das XA-Schnittstellenprotokoll. Basierend auf den ideologischen Einstellungen des Koordinators und der Teilnehmer wurden 2PC und 3PC vorgeschlagen, um verteilte XA-Transaktionen zu implementieren.
Wie der Name schon sagt, ist dieser Prozess hauptsächlich in zwei Schritte unterteilt.
In der ersten Phase übermittelt der Koordinator (Transaktionsmanager) die betreffende Transaktion vorab. Zu diesem Zeitpunkt werden die Datenbankressourcen gesperrt. Teilnehmer schreiben Rückgängig und Wiederherstellen in das Transaktionsprotokoll.
In der zweiten Phase schreibt der Teilnehmer (Ressourcenmanager) die Transaktion fest oder verwendet das Rückgängig-Protokoll, um die Transaktion rückgängig zu machen und Ressourcen freizugeben.
Der gesamte Vorgang ist wie unten dargestellt.
Erfolgsszenario für die Übermittlung verteilter Transaktionen:
Rollback-Szenario für verteilte Transaktionen:
Die Vorteile dieser Lösung sind: relativ einfache Implementierung, Unterstützung durch gängige Datenbanken und starke Konsistenz. MySQL 5.5 und höher werden auf Basis des XA-Protokolls implementiert.
Die entsprechende Lösung weist auch Mängel auf:
Das Einzelpunktproblem des Koordinators. Wenn der Koordinator während der Einreichungsphase ausfällt und die Teilnehmer warten, werden die Ressourcen gesperrt und blockiert. Eine Wiederwahl des Koordinators ist zwar möglich, löst das Problem jedoch nicht.
Die Synchronisierungsblockierungszeit ist zu lang. Die gesamte Ausführungsprozesstransaktion wird aufgrund einer Netzwerkverzögerung blockiert, bis die Übermittlung abgeschlossen ist und Ressourcen freigegeben werden , wurden die Teilnehmer gesperrt. Erfolgt keine Weisung, bleibt der Teilnehmer gesperrt.
Die Daten sind inkonsistent. In der zweiten Phase sendet der Koordinator das erste Festschreibungssignal und geht dann aus. Dann schreibt der erste Teilnehmer die Transaktion fest, und der zweite Teilnehmer kann die Transaktion nicht festschreiben, da er das Koordinatorsignal nicht erhalten hat.
Auf der Grundlage der Mängel von 2PC wurde ein Verbesserungsplan vorgeschlagen, 3PC.
Dreiphasen-Einreichung, basierend auf der Zwei-Phasen-Einreichung, verbessert die beiden Phasen. Die dreistufigen Schritte sind wie folgt.
CanCommit, der Koordinator fragt den Teilnehmer, ob die Transaktion festgeschrieben werden kann.
PreCommit: Wenn alle Teilnehmer die Transaktion festschreiben können, gibt der Koordinator den PreCommit-Befehl aus, und die Teilnehmer sperren die Ressourcen und warten auf den endgültigen Befehl.
Alle Teilnehmer geben Bestätigungsinformationen zurück, und der Koordinator gibt für jede Transaktion Transaktionsausführungsbenachrichtigungen aus, sperrt Ressourcen und gibt den Ausführungsstatus zurück.
Einige Teilnehmer gaben Ablehnungsinformationen zurück oder der Koordinator hatte eine Zeitüberschreitung. In diesem Fall geht der Koordinator davon aus, dass die Transaktion nicht normal ausgeführt werden kann, gibt einen Unterbrechungsbefehl aus und jeder Teilnehmer verlässt den Vorbereitungszustand
Do Commit: Wenn alle Antworten auf die Bestätigung in der zweiten Phase ausgegeben werden, wird „Do Commit“ für die endgültige Transaktionsübermittlung ausgegeben, andernfalls wird ein Befehl zum Unterbrechen der Transaktion ausgegeben, und alle Teilnehmer werden dies tun Machen Sie die Transaktion rückgängig.
Alle Teilnehmer führen Transaktionen normal aus und der Koordinator gibt endgültige Commit-Anweisungen aus, um gesperrte Ressourcen freizugeben.
Einige Teilnehmer konnten die Transaktion nicht ausführen, der Koordinator hatte eine Zeitüberschreitung und der Koordinator gab einen Rollback-Befehl aus, um die gesperrten Ressourcen freizugeben.
Einzelheiten finden Sie im Bild unten.
Dreiphasige Übermittlung im Vergleich zu zwei Phasen, Einführung eines Timeout-Mechanismus, um Transaktionsblockierungen zu reduzieren und einzelne Fehlerquellen zu beheben. Sobald der Teilnehmer in der dritten Phase das Koordinatorsignal nicht empfängt, führt er nach dem Warten auf eine Zeitüberschreitung standardmäßig ein Commit aus und gibt Ressourcen frei.
Die drei Stufen können das Datenkonsistenzproblem immer noch nicht lösen. Wenn der Koordinator einen Rollback-Befehl ausgibt, die Teilnehmer ihn jedoch aufgrund von Netzwerkproblemen nicht innerhalb der Wartezeit empfangen können, schreiben die Teilnehmer die Transaktion standardmäßig fest und andere Transaktionen werden zurückgesetzt, was zu Transaktionsinkonsistenzen führt.
TCC-Transaktion
Um das Problem der Ressourcensperre mit großer Granularität während der Transaktionsausführung zu lösen, schlägt die Branche ein neues Transaktionsmodell vor, das auf dem basiert Transaktionsdefinition auf Geschäftsebene. Die Sperrgranularität wird vollständig vom Unternehmen selbst gesteuert. Es handelt sich im Wesentlichen um eine Kompensationsidee. Es unterteilt den laufenden Transaktionsprozess in zwei Phasen: Versuchen und Bestätigen/Abbrechen. Die Logik in jeder Phase wird durch Geschäftscode gesteuert. Auf diese Weise kann die Sperrgranularität der Transaktion vollständig frei gesteuert werden. Unternehmen können auf Kosten der Isolation eine höhere Leistung erzielen.
TCC ist die Abkürzung für „Trying“, „Confirm“ und „Cancel“. Im Gegensatz zu 2PC und 3PC, die auf der Datenbankebene basieren, basiert TCC auf der Anwendungsebene.
Die drei TCC-Aktionen sind:
Versuchen:
Alle Geschäftsprüfungen abschließen (Konsistenz)
Erforderliche Geschäfte reservieren Ressourcen (Quasi-Isolation)
Bestätigen:
Echte Geschäftsausführung
Die Bestätigung Der Vorgang muss die Idempotenz erfüllen
Abbrechen:
Die in der Testphase reservierten Geschäftsressourcen freigeben
Die Abbruchoperation muss der Idempotenz genügen
Die obige Aussage klingt vielleicht etwas umständlich und schwer zu verstehen, aber das spielt keine Rolle.
Nachfolgend simulieren wir einen Bezahlvorgang im Einkaufszentrum. Benutzer verwenden bei der Bestellung eine kombinierte Zahlung, d. h. Restbetrag plus Zahlung mit rotem Umschlag. Ein normaler Vorgang ist:
Bestellung erstellen
Bestellung aufgeben
Guthaben abrufen System, ziehen Sie den Restbetrag ab
Rufen Sie das System mit dem roten Umschlag auf, ziehen Sie den Restbetrag mit dem roten Umschlag ab
Ändern Sie den Bestellstatus auf „Bezahlt“
Zahlung nach Fertigstellung.
Der tatsächliche Prozess ist wie unten dargestellt.
Ein solcher Zahlungsvorgang ruft jedoch mehrere Unterdienste auf, und wir können nicht garantieren, dass alle Dienste erfolgreich sein können. Beispielsweise rufen wir an Das System der roten Umschläge schlägt fehl. Zu diesem Zeitpunkt stießen wir auf eine peinliche Szene. Aufgrund des Ausfalls des Red-Envelope-Dienstes wurde die Methode abnormal beendet. Zu diesem Zeitpunkt war der Bestellstatus der ursprüngliche Status, aber das Benutzerguthaben wurde abgezogen. Dies ist sehr unfreundlich für die Benutzererfahrung. Daher müssen wir während dieses Zahlungsprozesses über einen Mechanismus verfügen, um diesen Prozess als Gesamtverhalten zu behandeln, und wir müssen sicherstellen, dass alle Serviceaufrufe in diesem Prozess entweder erfolgreich sind oder fehlschlagen und zu einer gesamten Transaktion werden.
Zu diesem Zeitpunkt können wir TCC-Transaktionen einführen, um den gesamten Bestellvorgang als Ganzes zu behandeln. Nach der Einführung haben wir zu diesem Zeitpunkt das Bestellsystem und das Red-Envelope-System zurückgesetzt, da der Abzug des Guthabensystems fehlgeschlagen ist. Der gesamte Vorgang ist unten dargestellt.
Aufgrund des Ausfalls des Balance-Systems müssen wir alle Änderungen in diesem Prozess rückgängig machen, daher senden wir eine Stornierungsbenachrichtigung an das Bestellsystem und ein rotes Umschlagsystem Widerrufsbelehrung.
Nachdem das System TCC-Transaktionen eingeführt hat, müssen wir unseren Anrufprozess umgestalten.
Gemäß den drei Schritten von TCC-Transaktionen müssen wir zu diesem Zeitpunkt jeden Dienst in drei Schritte von Try Confirm Cancelle umwandeln,
TCC VERSUCHEN:
Basierend auf dem oben genannten Geschäft fügt das Bestellsystem eine Testmethode hinzu, um den Bestellstatus auf BEZAHLT zu ändern. Das Saldosystem fügt eine Try-Methode hinzu, die zunächst prüft, ob der Saldo ausreicht, dann den Saldo abzieht und dann den abgezogenen Saldo zum eingefrorenen Betrag hinzufügt. Das Red-Envelope-System ist dasselbe wie das Balance-System. Aus dem Transformationsprozess ist ersichtlich, dass die TCC-Try-Methode jede Geschäftsressource überprüfen muss und dieser Prozess Zwischenzustände einführen muss. Schauen wir uns den gesamten Prozess anhand des Bildes unten an.
TCC-Bestätigung:
TCC Schritt 1 VERSUCHEN Wenn alle Unterdienstaufrufe erfolgreich sind, müssen wir zu diesem Zeitpunkt bestätigen jeder Aufschlag. Fügen Sie jedem Dienst eine Bestätigungsmethode hinzu. Beispielsweise wird die Bestätigungsmethode des Bilanzsystems verwendet, um den eingefrorenen Betrag auf 0 zu setzen, und das System des roten Umschlags ist wie oben. Das Bestellsystem ändert den Bestellstatus auf ERFOLGREICH. Bei der Bestätigungsmethode muss darauf geachtet werden, Idempotenz zu erreichen. Bevor Sie beispielsweise das Bestellsystem aktualisieren, müssen Sie zunächst feststellen, dass der Bestellstatus BEZAHLT lautet, bevor Sie die Bestellung aktualisieren können. Der gesamte Vorgang ist unten dargestellt.
An diesem Punkt muss das TCC-Transaktionsframework verwendet werden, um jeden Dienst zu bewerben. Nachdem der TCC-Transaktionsmanager das Ende der TRY-Methode erkannt hat, ruft er automatisch die von jedem Dienst bereitgestellte Bestätigungsmethode auf, um den Status jedes Dienstes in den endgültigen Zustand zu ändern.
TCC-Abbruch:
Wenn die Methode zum Einfrieren des roten Umschlags während des TCC-Testvorgangs fehlschlägt, müssen wir alle vorherigen Änderungen rückgängig machen und sie in ihren ursprünglichen Zustand zurückversetzen. Die Cancle-Methode muss auch Idempotenz wie die Bestätigungsmethode implementieren, wie unten gezeigt:
Wenn wir dies sehen, können wir sehen, dass TCC Try erfolgreich ist und Bestätigen muss erfolgreich sein, Versuch schlägt fehl und Abbrechen muss erfolgreich sein. Denn die Bestätigung ist der Schlüssel zur Aktualisierung des Systems auf den Endzustand. Aber die Realität ist so rücksichtslos, dass die Möglichkeit besteht, dass die Bestätigung oder der Abbruch im Produktionssystem fehlschlägt. In diesem Fall muss das TCC-Framework das Ergebnis des Bestätigungsaufrufs aufzeichnen. Wenn der Bestätigungsaufruf fehlschlägt, muss das TCC-Framework ihn aufzeichnen und ihn dann in einem bestimmten Intervall erneut aufrufen.
Zusammenfassung und Überlegungen
Nachdem Sie den vollständigen Text gelesen haben, sollten Sie verteilte Transaktionen grundsätzlich verstehen.
Auf dieser Grundlage fassen wir dies zusammen. Um verteilte Transaktionen nutzen zu können, müssen wir sie in Verbindung mit unseren tatsächlichen Szenarien anwenden.
Wenn sich das Unternehmen noch in der Anfangsphase befindet, können wir tatsächlich Datenbanktransaktionen auswählen, um eine schnelle Online-Iteration sicherzustellen.
Wenn das Unternehmen ein bestimmtes Stadium erreicht, beginnt die Aufteilung des Systems und auch der Datenbank. Wenn das Unternehmen zu diesem Zeitpunkt Konsistenz gewährleisten muss, müssen verteilte Transaktionen verwendet werden. Wenn wir derzeit verteilte Transaktionen verwenden, müssen wir je nach Geschäft überlegen, welche wir verwenden möchten.
Mit dem von 2PC oder 3PC implementierten verteilten Framework muss die Geschäftsanwendungsschicht nicht geändert werden und der Zugriff ist relativ einfach. Allerdings ist die entsprechende Leistung gering und die Datenressourcen sind für lange Zeit gesperrt. Nicht geeignet für Geschäftsszenarien mit hoher Parallelität wie das Internet.
Die Verwendung eines TCC-basierten verteilten Frameworks bietet eine höhere Leistung als 2PC und kann die endgültige Konsistenz der Daten sicherstellen. Für die Anwendungsschicht muss jedoch eine Methode in drei Methoden umgewandelt werden und einige Zwischenzustände müssen in das Unternehmen eingeführt werden. Relativ gesehen ist der Grad der Anwendungstransformation relativ groß.
Das obige ist der detaillierte Inhalt vonDetaillierte grafische Erläuterung verteilter Transaktionen. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!
![[Web-Frontend] Node.js-Schnellstart](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
