Vertiefte Kenntnisse verteilter JAVA-Transaktionen

Dieser Artikel führt hauptsächlich in ein tiefgreifendes Verständnis der verteilten JAVA-Transaktionen ein. Der Herausgeber findet ihn recht gut. Jetzt werde ich ihn mit Ihnen teilen und Ihnen eine Referenz geben. Folgen wir dem Editor und werfen wir einen Blick darauf.

1. Was ist eine verteilte Transaktion? Die Transaktions- und Ressourcenserver- und Transaktionsmanager befinden sich auf verschiedenen Knoten in verschiedenen verteilten Systemen. Das Obige ist die Erklärung aus der Baidu-Enzyklopädie. Eine große Operation besteht aus verschiedenen kleinen Operationen, die auf verschiedene Server verteilt sind und zu verschiedenen Anwendungen gehören alle scheitern. Im Wesentlichen sollen verteilte Transaktionen die Datenkonsistenz in verschiedenen Datenbanken sicherstellen.

2. Gründe für verteilte Transaktionen

2.1. Datenbankunterdatenbank und -tabelle

Wenn die Daten von einer einzelnen Datenbanktabelle in einem Jahr generiert werden Übersteigt die Leistung 1000 W, müssen wir das Datenbank- und Tabellen-Sharding berücksichtigen. Ich werde hier nicht näher darauf eingehen, um es einfach auszudrücken: Die ursprüngliche Datenbank ist zu mehreren geworden Datenbanken. Wenn zu diesem Zeitpunkt eine Operation sowohl auf die 01-Bibliothek als auch auf die 02-Bibliothek zugreift und die Konsistenz der Daten sichergestellt werden muss, müssen verteilte Transaktionen verwendet werden.

2.2. SOA anwenden

Die sogenannte SOA ist das serviceorientierte Geschäft. Beispielsweise unterstützte ursprünglich eine einzelne Maschine die gesamte E-Commerce-Website, doch nun wurde die gesamte Website demontiert und in das Bestellzentrum, das Benutzerzentrum und das Inventarzentrum aufgeteilt. Für das Bestellzentrum gibt es eine spezielle Datenbank zum Speichern von Bestellinformationen, das Benutzerzentrum verfügt außerdem über eine spezielle Datenbank zum Speichern von Benutzerinformationen und das Inventarzentrum verfügt außerdem über eine spezielle Datenbank zum Speichern von Inventarinformationen. Wenn Sie zu diesem Zeitpunkt Bestellungen und Lagerbestände gleichzeitig bearbeiten möchten, sind die Auftragsdatenbank und die Lagerbestandsdatenbank erforderlich. Um die Datenkonsistenz sicherzustellen, müssen Sie verteilte Transaktionen verwenden.

Die beiden oben genannten Situationen sehen unterschiedlich aus, sind aber im Wesentlichen gleich, da mehr Datenbanken zu bedienen sind!

3. ACID-Eigenschaften von Transaktionen

3.1. Atomizität (A)

Die sogenannte Atomizität bedeutet, dass alle Vorgänge in der gesamten Transaktion entweder abgeschlossen sind oder nichts bewirken , dazwischen gibt es nicht. Wenn während der Transaktionsausführung ein Fehler auftritt, werden alle Vorgänge zurückgesetzt und die gesamte Transaktion wird so sein, als ob sie nie ausgeführt worden wäre.

3.2. Konsistenz (C)

Die Ausführung von Transaktionen muss die Konsistenz des Systems sicherstellen Wenn A in einer Transaktion erfolgreich 50 Yuan an B überweist, dann muss Konto A am Ende 450 Yuan betragen, egal wie viele Parallelen es gibt, egal was passiert, solange die Transaktion erfolgreich ausgeführt wird Konto B muss 350 Yuan betragen.

3.3. Isolation (I)

Die sogenannte Isolation bedeutet, dass sich Transaktionen nicht gegenseitig beeinflussen und der Zwischenstatus einer Transaktion nicht „Andere Transaktion“ ist Bewusstsein.

3.4. Haltbarkeit (D)

Die sogenannte Persistenz bedeutet, dass nach Abschluss einer einzelnen Transaktion die durch die Transaktion vorgenommenen Änderungen an den Daten vollständig sind Die Daten werden in der Datenbank gespeichert, auch wenn es zu einem Stromausfall oder einem Systemausfall kommt.

4. Anwendungsszenarien verteilter Transaktionen

Das klassischste Szenario ist die Zahlung Wenn Sie gleichzeitig Geld auf das Privatkonto des Verkäufers einzahlen und Geld auf das Konto des Verkäufers einzahlen, müssen diese Vorgänge in einer einzigen Transaktion durchgeführt werden. Entweder sind alle erfolgreich oder alle fehlschlagen. Das Konto des Käufers, das zum Käuferzentrum gehört, entspricht der Datenbank des Käufers, während das Konto des Verkäufers zum Zentrum des Verkäufers gehört, das der Datenbank des Verkäufers entspricht. Operationen an verschiedenen Datenbanken müssen verteilte Transaktionen einleiten.

4.2. Online-Bestellung

Käufer, die Bestellungen auf E-Commerce-Plattformen aufgeben, umfassen oft zwei Aktionen: eine besteht darin, den Lagerbestand abzuziehen, und die zweite darin, den Bestellstatus zu aktualisieren. Inventar und Bestellungen gehören im Allgemeinen zu unterschiedlichen Datenbanken, und verteilte Transaktionen müssen verwendet werden, um die Datenkonsistenz sicherzustellen.

5. Gemeinsame verteilte Transaktionslösungen

2-Phasen-Übermittlung basierend auf dem XA-Protokoll

XA ist ein von Tuxedo vorgeschlagenes verteiltes Transaktionsprotokoll. XA ist grob in zwei Teile unterteilt: Transaktionsmanager und lokaler Ressourcenmanager. Der lokale Ressourcenmanager wird häufig von einer Datenbank implementiert. Kommerzielle Datenbanken wie Oracle und DB2 implementieren alle die XA-Schnittstelle, und der Transaktionsmanager fungiert als globaler Scheduler und ist für die Übermittlung und das Rollback jeder lokalen Ressource verantwortlich. Das Prinzip der XA-Implementierung verteilter Transaktionen ist wie folgt:

Im Allgemeinen ist das XA-Protokoll relativ einfach, und sobald eine kommerzielle Datenbank das XA implementiert Protokoll, Verwendung Die Kosten für verteilte Transaktionen sind ebenfalls relativ gering. Allerdings weist XA auch einen schwerwiegenden Mangel auf, nämlich dass seine Leistung nicht ideal ist, insbesondere bei der Transaktionsauftragsverknüpfung, die häufig ein hohes Maß an Parallelität aufweist, und XA nicht in der Lage ist, Szenarien mit hoher Parallelität zu erfüllen. XA wird derzeit in kommerziellen Datenbanken optimal unterstützt, in MySQL-Datenbanken jedoch nicht so gut. Die XA-Implementierung von MySQL zeichnet keine Protokolle der Vorbereitungsphase auf, und das Zurückschalten zwischen der aktiven und der Standby-Datenbank führt zu Dateninkonsistenzen zwischen der aktiven und der Standby-Datenbank. Viele Nosql unterstützen XA auch nicht, was die Anwendungsszenarien von XA sehr eng macht.

5.2. Nachrichtentransaktion + eventuelle Konsistenz

Die sogenannte Nachrichtentransaktion ist eine zweistufige Übermittlung basierend auf Nachrichten-Middleware, bei der es sich im Wesentlichen um eine Art Nachrichten-Middleware handelt Bei der speziellen Verwendung werden lokale Transaktionen und das Senden von Nachrichten in eine verteilte Transaktion eingefügt, um sicherzustellen, dass entweder der lokale Vorgang erfolgreich ist und die externe Nachricht erfolgreich gesendet wird. Das spezifische Prinzip lautet wie folgt:

1System A sendet eine vorbereitete Nachricht an die Nachrichten-Middleware
2. Die Nachrichten-Middleware speichert die vorbereitete Nachricht und gibt Erfolg zurück
3. A führt eine lokale Transaktion aus
4. A sendet eine Commit-Nachricht an die Nachrichten-Middleware

Eine Nachrichtentransaktion wird durch die oben genannten 4 Schritte abgeschlossen. Bei den oben genannten 4 Schritten kann jeder Schritt Fehler verursachen. Lassen Sie uns sie einzeln analysieren:

• Wenn im ersten Schritt ein Fehler auftritt, schlägt die gesamte Transaktion fehl und wird nicht ausgeführt.

• Wenn in Schritt zwei ein Fehler auftritt, schlägt die gesamte Transaktion fehl und die lokale Operation von A

• wird nicht ausgeführt

  Zu diesem Zeitpunkt ist ein Fehler aufgetreten. Die Vorbereitungsmeldung muss zurückgesetzt werden. Die Antwort ist, dass System A eine Rückrufschnittstelle für Nachrichten-Middleware implementiert, um zu überprüfen, ob Transaktion A erfolgreich ausgeführt wurde. Wenn sie fehlschlägt, wird die vorbereitete Nachricht zurückgesetzt

• In Schritt 4 ist ein Fehler aufgetreten. Zu diesem Zeitpunkt ist die lokale Transaktion von A erfolgreich. Muss die Nachrichten-Middleware A zurücksetzen? Die Antwort lautet: Nein. Tatsächlich kann die Nachrichten-Middleware überprüfen, ob A erfolgreich ausgeführt wurde. Zu diesem Zeitpunkt besteht für A keine Notwendigkeit, die Nachricht selbst zu senden , wodurch die gesamte Nachrichtentransaktion abgeschlossen wird

Zweiphasiges Commit basierend auf Nachrichten-Middleware wird häufig in Szenarien mit hoher Parallelität verwendet, um eine verteilte Transaktion in eine Nachrichtentransaktion aufzuteilen (lokaler Betrieb von System A + Nachrichtenversand) + lokaler Betrieb von System B. Der Betrieb von System B wird durch Nachrichten gesteuert. Solange die Nachrichtentransaktion erfolgreich ist, muss der Betrieb von A erfolgreich sein und die Nachricht muss gesendet werden. Zu diesem Zeitpunkt empfängt B die Nachricht zur Durchführung der lokalen Operation. Wenn die lokale Operation fehlschlägt, wird die Nachricht erneut zugestellt, bis die Operation von B erfolgreich ist, wodurch die verteilte Transaktion von A und B verdeckt realisiert wird. Das Prinzip lautet wie folgt:

Obwohl die obige Lösung die Operationen von A und B vervollständigen kann, sind A und B nicht streng konsistent, aber letztendlich Konsequent Ja, wir haben hier Konstanz geopfert und dafür eine deutliche Leistungsverbesserung erhalten. Natürlich ist diese Art des Gameplays auch riskant. Wenn B weiterhin nicht ausgeführt wird, wird die Konsistenz zerstört. Ob es gespielt wird, hängt davon ab, wie viel Risiko das Unternehmen tragen kann.

5.3, TCC-Programmiermodus

Der sogenannte TCC-Programmiermodus ist ebenfalls eine Variante der zweiphasigen Einreichung. TCC bietet ein Programmierframework, das die gesamte Geschäftslogik in drei Teile unterteilt: Vorgänge ausprobieren, bestätigen und abbrechen. Am Beispiel einer Online-Bestellung wird in der Phase „Testen“ der Lagerbestand abgezogen und in der Phase „Bestätigen“ der Bestellstatus aktualisiert. Wenn die Bestellaktualisierung fehlschlägt, geht es in die Phase „Stornieren“ über und der Lagerbestand wird wiederhergestellt. Kurz gesagt, TCC implementiert die zweistufige Übermittlung künstlich durch Code. Die in verschiedenen Geschäftsszenarien geschriebenen Codes sind unterschiedlich und auch die Komplexität ist unterschiedlich. Daher kann dieses Modell nicht gut wiederverwendet werden.

6. Zusammenfassung

Verteilte Transaktionen sind im Wesentlichen eine einheitliche Kontrolle von Transaktionen in mehreren Datenbanken. Je nach Intensität der Kontrolle können sie unterteilt werden in: keine Kontrolle und teilweise Kontrolle und vollständige Kontrolle. Keine Kontrolle bedeutet, dass keine verteilten Transaktionen eingeführt werden, einschließlich der oben erwähnten Nachrichtentransaktion + Eventual Consistency und des TCC-Modus. Der Vorteil der teilweisen Kontrolle besteht darin, dass Parallelität und Leistung sehr gut sind. Der Nachteil besteht darin, dass die vollständige Kontrolle die Leistung beeinträchtigt und die Konsistenz gewährleistet. Als Techniker dürfen Sie nicht vergessen, dass Technologie dem Unternehmen dient. Auch die Technologieauswahl ist für verschiedene Unternehmen eine sehr wichtige Fähigkeit.

Das obige ist der detaillierte Inhalt vonVertiefte Kenntnisse verteilter JAVA-Transaktionen. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!