XA-Spezifikation
XA ist die Schnittstellenspezifikation (d. h. Schnittstellenfunktion) zwischen der Transaktions-Middleware und der von X/Open DTP definierten Datenbank, die von der Transaktions-Middleware verwendet wird, um die Datenbank über Start, Ende, Commit, Rollback usw. von Transaktionen zu informieren. XA-Schnittstellenfunktionen werden von Datenbankanbietern bereitgestellt.
Die Zweitordnungs-Einreichungsvereinbarung und die Drittordnungs-Einreichungsvereinbarung wurden aus dieser Idee abgeleitet. Man kann sagen, dass zweistufige Commits tatsächlich der Schlüssel zur Implementierung von XA-verteilten Transaktionen sind (genauer gesagt: Zweistufige Commits sorgen hauptsächlich für die Atomizität verteilter Transaktionen: das heißt, alle Knoten machen entweder alles oder gar nichts)
2PC
Zweiphasen-Commit bezeichnet einen Algorithmus, der darauf ausgelegt ist, Konsistenz bei Transaktionscommits für alle Knoten auf Basis der verteilten Systemarchitektur im Bereich der Computernetzwerke und Datenbanken zu gewährleisten. Oft wird ein zweistufiges Commit auch als Protokoll bezeichnet. In einem verteilten System kann jeder Knoten den Erfolg oder Misserfolg seiner eigenen Operation kennen, aber er kann den Erfolg oder Misserfolg der Operationen anderer Knoten nicht kennen. Wenn eine Transaktion mehrere Knoten umfasst, muss zur Aufrechterhaltung der ACID-Eigenschaften der Transaktion eine Komponente eingeführt werden, die als Koordinator fungiert, um die Ergebnisse aller Knoten (sogenannte Teilnehmer) zu steuern und diese Knoten letztlich anzuweisen, die Ergebnisse tatsächlich zu senden (z. B. aktualisierte Daten auf Festplatte zu schreiben usw.). Daher lässt sich die Algorithmenidee der zweistufigen Einreichung wie folgt zusammenfassen: Die Teilnehmer informieren den Koordinator über Erfolg oder Misserfolg der Operation, und anschließend entscheidet der Koordinator, ob die Operation eingereicht oder abgebrochen wird, basierend auf den Rückmeldungen aller Teilnehmer.
Die sogenannten zwei Phasen sind: die erste Phase: die Vorbereitungsphase (Abstimmungsphase) und die zweite Phase: die Einreichungsphase (Ausführungsphase).
Vorbereitungsphase
Der Transaktionskoordinator (Transaktionsmanager) sendet an jeden Teilnehmer (Ressourcenmanager) eine Vorbereitungsnachricht, und jeder Teilnehmer gibt entweder direkt einen Fehler zurück (wie eine fehlgeschlagene Berechtigungsverifikation) oder führt die Transaktion lokal aus, schreibt lokale Logs zum Erneuten und Rückgängigmachen, committiert aber nicht und erreicht den Zustand "Alles ist bereit, nur der Ostwind ist schuldet".
Die Vorbereitungsphase lässt sich weiter in die folgenden drei Schritte unterteilen:
1) Der Koordinatorknoten fragt alle Teilnehmerknoten, ob sie eine Abstimmung durchführen können, und beginnt mit dem Warten auf eine Antwort von jedem Teilnehmerknoten.
2) Der teilnehmende Knoten führt alle Transaktionsoperationen durch, bis die Abfrage gestartet wird, und schreibt die Rückgängig- und Redo-Informationen ins Protokoll. (Hinweis: Bei Erfolg hat jeder Teilnehmer die Transaktionsoperation bereits durchgeführt.)
3) Jeder Teilnehmerknoten antwortet auf die vom Koordinatorknoten initiierte Anfrage. Wenn die Transaktionsoperation des teilnehmenden Knotens tatsächlich erfolgreich ausgeführt wird, wird eine "Agree"-Nachricht zurückgegeben; Wenn die Transaktionsoperation des teilnehmenden Knotens tatsächlich fehlschlägt, wird eine "abgebrochene" Nachricht zurückgegeben.
Submission-Phase
Wenn der Koordinator eine Fehlermeldung oder ein Timeout von einem Teilnehmer erhält, sendet er eine Rollback-Nachricht direkt an jeden Teilnehmer. Ansonsten senden Sie eine Commit-Nachricht; Teilnehmer führen Commit- oder Rollback-Operationen gemäß den Anweisungen des Koordinators durch, um alle im Transaktionsprozess verwendeten Sperrressourcen freizugeben. (Hinweis: Lock-Ressourcen müssen in der letzten Phase freigegeben werden)
Als Nächstes wird der Ablauf der Einreichungsphase in zwei Fällen separat besprochen.
Wenn die entsprechende Nachricht, die vom Koordinatorknoten von allen teilnehmenden Knoten empfangen wird, Agree lautet:
Submission-Phase
Wenn der Koordinator eine Fehlermeldung oder ein Timeout von einem Teilnehmer erhält, sendet er eine Rollback-Nachricht direkt an jeden Teilnehmer. Ansonsten senden Sie eine Commit-Nachricht; Teilnehmer führen Commit- oder Rollback-Operationen gemäß den Anweisungen des Koordinators durch, um alle im Transaktionsprozess verwendeten Sperrressourcen freizugeben. (Hinweis: Lock-Ressourcen müssen in der letzten Phase freigegeben werden)
Als Nächstes wird der Ablauf der Einreichungsphase in zwei Fällen separat besprochen.
Wenn die entsprechende Nachricht, die vom Koordinatorknoten von allen teilnehmenden Knoten empfangen wird, Agree lautet:
1) Der Koordinatorknoten stellt eine "Committ"-Anfrage an alle teilnehmenden Knoten.
2) Der teilnehmende Knoten schließt die Operation offiziell ab und gibt die während des gesamten Transaktionszeitraums belegten Ressourcen frei.
3) Der Teilnehmerknoten sendet eine "Erledigt"-Nachricht an den Koordinatorknoten.
4) Der Koordinatorknoten schließt die Transaktion ab, nachdem er das Feedback der "Erledigt"-Nachricht von allen teilnehmenden Knoten erhalten hat.
1) Der Koordinatorknoten stellt eine "Rollback"-Anfrage an alle teilnehmenden Knoten.
2) Der teilnehmende Knoten nutzt die zuvor geschriebenen Rückgängigkeitsinformationen, um einen Rollback durchzuführen und Ressourcen freizugeben, die während des gesamten Transaktionszeitraums belegt sind.
3) Der Teilnehmerknoten sendet eine "Rollback abgeschlossen"-Nachricht an den Koordinatorknoten.
4) Der Koordinatorknoten hebt die Transaktion nach Erhalt der Rückmeldung "Rollback Complete" von allen teilnehmenden Knoten ab.
Phase-2-Comits scheinen atomare Operationen bereitzustellen, aber leider haben Phase-2-Comits dennoch einige Nachteile:
1. Problem mit synchroner Blockierung. Während der Ausführung blockieren alle teilnehmenden Knoten Transaktionen. Wenn ein Teilnehmer eine öffentliche Ressource besetzt, müssen andere Drittanbieter-Knoten daran gehindert werden, auf die öffentliche Ressource zuzugreifen.
2. Ein einzelner Fehlerpunkt. Aufgrund der Bedeutung des Koordinators, sobald der Koordinator versagt. Die Teilnehmer werden die Blockade weiterhin blockieren. Insbesondere in der zweiten Phase, wenn der Koordinator fehlschlägt, befinden sich alle Teilnehmer weiterhin in einem Zustand, in dem Transaktionsressourcen gesperrt sind, und können die Transaktionsoperationen nicht weiter abschließen. (Wenn der Koordinator auflegt, kannst du einen Koordinator wiederwählen, aber das löst nicht das Problem, dass der Teilnehmer blockiert ist, weil der Koordinator ausfällt.)
3. Dateninkonsistenz. In der zweiten Phase der zweiten Phase des Commits, wenn der Koordinator eine Commit-Anfrage an den Teilnehmer sendet, tritt eine lokale Netzwerk-Ausnahme auf oder der Koordinator scheitert während des Commit-Anfrage-Prozesses, wodurch nur einige Teilnehmer die Commit-Anfrage akzeptieren. Nach Erhalt der Commit-Anfrage führen diese Teilnehmer die Commit-Operation durch. Allerdings können andere Maschinen, die keine Commit-Anfrage erhalten, die Transaktion nicht ausführen. Dadurch tritt die Konsistenz der Datenabteilung im gesamten verteilten System auf.
4. Probleme, die in der zweiten Phase nicht gelöst werden können: Der Koordinator fällt nach dem Senden einer Commit-Nachricht aus, und der einzige Teilnehmer, der diese Nachricht empfängt, fällt ebenfalls aus. Selbst wenn der Facilitator also durch die Wahlvereinbarung einen neuen Facilitator wählt, ist der Status der Transaktion ungewiss, und niemand weiß, ob die Transaktion eingereicht wurde.
3PC
Dreiphasen-Commit, auch bekannt als Drei-Phasen-Commit-Protokoll, ist eine verbesserte Version des Zwei-Phasen-Commit (2PC).
Im Gegensatz zu zweistufigen Comits gibt es zwei Änderungen bei dreistufigen Comits.
1. Führen Sie einen Auszeitmechanismus ein. Gleichzeitig wird sowohl beim Moderator als auch bei den Teilnehmern ein Auszeitmechanismus eingeführt.
2. Fügen Sie eine Vorbereitungsstufe in die erste und zweite Stufe ein. Dies stellt sicher, dass der Zustand aller teilnehmenden Knoten bis zur finalen Commit-Phase konsistent bleibt.
Mit anderen Worten: Neben der Einführung eines Timeout-Mechanismus teilt 3PC die Vorbereitungsphase von 2PC erneut in zwei Phasen, sodass es in den drei Phasen des Commit drei Phasen CanCommit, PreCommit und DoCommit gibt.
CanCommit-Phase
Die CanCommit-Phase von 3PC ist tatsächlich der Vorbereitungsphase von 2PC sehr ähnlich. Der Koordinator sendet eine Commit-Anfrage an den Teilnehmer, der eine Ja-Antwort zurückgibt, falls er sich festlegen kann, oder eine Nein-Antwort.
1. Transaktionsanfrage Der Vermittler sendet eine CanCommit-Anfrage an den Teilnehmer. Frag, ob du eine Transaktionscommitt-Operation durchführen kannst. Dann fangen Sie an, auf eine Antwort der Teilnehmer zu warten.
2. Antwort-Feedback Nach Erhalt der CanCommit-Anfrage gibt der Teilnehmer eine Ja-Antwort zurück und tritt in den Bereitschaftszustand ein, wenn er glaubt, dass die Transaktion reibungslos ausgeführt werden kann. Ansonsten Feedback Nein
PreCommit-Phase
Der Facilitator entscheidet, ob er die PreCommit-Operation der Transaktion basierend auf der Antwort des Teilnehmers auswendig lernt oder nicht. Je nach Reaktion gibt es zwei Möglichkeiten.
Wenn das Feedback, das der Facilitator von allen Teilnehmern erhält, ein Ja-Feedback ist, wird die Vorab-Ausführung der Transaktion durchgeführt.
1. Senden Sie eine PreCommit-Anfrage: Der Facilitator sendet eine PreCommit-Anfrage an den Teilnehmer und geht in die Vorbereitungsphase über.
2. Transaktions-Pre-Commit Nachdem der Teilnehmer die PreCommit-Anfrage erhalten hat, führt er die Transaktionsoperation durch und zeichnet die Rückgängig- und Wiederholungsinformationen im Transaktionsprotokoll fest.
3. Antwort-Feedback Wenn der Teilnehmer die Transaktionsoperation erfolgreich ausführt, wird eine ACK-Antwort zurückgegeben, während auf die endgültige Anweisung gewartet wird.
1. Senden Sie eine Interrupt-Anfrage Der Facilitator sendet eine Abbruch-Anfrage an alle Teilnehmer.
2. Unterbrechen der Transaktion Nachdem der Teilnehmer die ABORT-Anfrage vom Koordinator erhalten hat (oder nach dem Timeout ist die Anfrage vom Koordinator nicht empfangen), wird die Unterbrechung der Transaktion ausgeführt.
Diese Phase des realen Transaktionscommit lässt sich auch in folgende zwei Situationen unterteilen.
Führe ein Commit aus
1. Senden Sie eine Commit-Anfrage Die Koordination erhält die ACK-Antwort des Teilnehmers, dann wechselt er vom Pre-Committ-Zustand zum Committ-Zustand. und senden Sie eine doCommit-Anfrage an alle Teilnehmer.
2. Transaktionsabgabe Nach Erhalt der doCommit-Anfrage führt der Teilnehmer die formelle Transaktionscommit aus. und alle Transaktionsressourcen nach Abschluss des Transaktionscommits freizugeben.
3. Antworten Sie auf Feedback Nachdem die Transaktion eingereicht wurde, senden Sie eine Ack-Antwort an den Koordinator.
4. Abschluss der Transaktion Nachdem der Koordinator die ACK-Antwort aller Teilnehmer erhalten hat, ist die Transaktion abgeschlossen.
Wenn der Koordinator keine ACK-Antwort vom Teilnehmer erhält (es muss keine ACK-Antwort vom Empfänger sein oder die Antwort ist abgelaufen), wird die Interrupt-Transaktion ausgeführt.
1. Senden Sie eine Unterbrechungsanforderung Der Facilitator sendet eine Abbruchsanfrage an alle Teilnehmer
2. Transaktionsrollback Nach Erhalt der ABORT-Anfrage verwendet der Teilnehmer die in Phase 2 aufgezeichneten Rückgängigkeitsinformationen zur Durchführung der Transaktionsrollback-Operation und gibt nach Abschluss des Rollbacks alle Transaktionsressourcen frei.
3. Rückmeldungsergebnisse Nachdem der Teilnehmer den Transaktionsrollback abgeschlossen hat, senden Sie eine ACK-Nachricht an den Koordinator
4. Unterbrechen Sie die Transaktion Nachdem der Koordinator die ACK-Nachricht vom Teilnehmer erhalten hat, wird die Transaktion unterbrochen.
Der Unterschied zwischen 2PC und 3PC
Im Vergleich zu 2PC löst 3PC hauptsächlich das Single Point of Failure-Problem und reduziert das Blockieren, denn sobald der Teilnehmer eine Nachricht vom Koordinator nicht rechtzeitig erhält, führt er standardmäßig das Commit aus. Anstatt ständig Transaktionsressourcen zurückzuhalten und in einem blockierenden Zustand zu sein. Dieser Mechanismus verursacht jedoch auch Probleme mit der Datenkonsistenz, da die vom Koordinator gesendete Abbruchsantwort aus Netzwerkgründen nicht rechtzeitig vom Teilnehmer empfangen wird und der Teilnehmer die Commit-Operation nach dem Warten auf den Timeout ausführt. Dies erzeugt Dateninkonsistenzen mit anderen Teilnehmern, die den Abbruchbefehl erhalten und einen Rollback durchführen.
|
Veröffentlicht am 17.03.2021 10:15:10
|
|
|
