Umfassendes Verständnis von Transaktionen in MySql_MySQL

Ich habe in letzter Zeit an auftragsbasierten Projekten gearbeitet und dabei Transaktionen verwendet. Unsere Datenbank verwendet MySql und die Speicher-Engine verwendet innoDB, das Transaktionen gut unterstützt. Werfen wir in diesem Artikel einen Blick auf das Wissen im Zusammenhang mit Angelegenheiten.

Warum brauchen wir Affären?

Transaktionen werden häufig in verschiedenen Szenarien wie Bestellsystemen und Banksystemen verwendet. Wenn das folgende Szenario vorliegt: Benutzer A und Benutzer B sind Einleger der Bank. Nun möchte A 500 Yuan an B überweisen. Dann müssen Sie die folgenden Dinge tun:

1. Überprüfen Sie den Kontostand von A >500 Yuan;

2. 500 Yuan von Konto A abziehen

3. Fügen Sie 500 Yuan zu Konto B hinzu

Nach dem normalen Vorgang wurden 500 von Konto A abgebucht und 500 auf Konto B gutgeschrieben. Alle waren zufrieden. Was passiert, wenn das System ausfällt, nachdem Geld von Konto A abgebucht wurde? A hat 500 vergeblich verloren und B hat die 500, die ihm gehören sollten, nicht erhalten. Im obigen Fall ist eine Voraussetzung verborgen: A, der Geld abzieht und B Geld hinzufügt, ist entweder gleichzeitig erfolgreich oder scheitert gleichzeitig. Das ist es, was das Geschäft erfordert.

Was ist die Transaktion?

Anstatt eine Transaktion zu definieren, ist es besser, über die Merkmale der Transaktion zu sprechen. Wie wir alle wissen, müssen Transaktionen die vier ACID-Merkmale erfüllen.

1. A(Atomizität) Atomizität. Die Ausführung einer Transaktion gilt als unteilbare Mindesteinheit. Die Vorgänge in der Transaktion müssen entweder erfolgreich ausgeführt werden oder zurückgesetzt werden, wenn sie fehlschlagen. Nur ein Teil davon kann nicht ausgeführt werden.

2. C(Konsistenz)-Konsistenz. Die Ausführung einer Transaktion sollte die Integritätsbeschränkungen der Datenbank nicht verletzen. Wenn das System nach der zweiten Operation im obigen Beispiel abstürzt, ist garantiert, dass sich die Gesamtsumme von A und B nicht ändert.

3. I(Isolation) Isolation. Im Allgemeinen sollte sich das Verhalten von Transaktionen nicht gegenseitig beeinflussen. In der Praxis wird jedoch der Grad der Interaktion von Transaktionen untereinander durch die Isolationsstufe beeinflusst. Einzelheiten dazu folgen später im Artikel.

4. D (Haltbarkeit) Haltbarkeit. Nachdem die Transaktion festgeschrieben wurde, muss die festgeschriebene Transaktion auf der Festplatte gespeichert werden. Auch bei einem Systemabsturz sollten die übermittelten Daten nicht verloren gehen.

Vier Isolationsstufen von Transaktionen

Wie im vorherigen Artikel erwähnt, wird die Isolation von Transaktionen durch die Isolationsstufe beeinflusst. Was ist also die Isolationsstufe einer Transaktion? Der Isolationsgrad einer Transaktion kann als der Grad des „Egoismus“ einer Transaktion betrachtet werden, der die Sichtbarkeit zwischen Transaktionen definiert. Isolationsstufen werden in die folgenden Typen unterteilt:

1.READ UNCOMMITTED (nicht festgeschriebenes Lesen). Unter der RU-Isolationsstufe sind die von Transaktion A an den Daten vorgenommenen Änderungen für Transaktion B sichtbar, auch wenn sie nicht festgeschrieben werden. Dieses Problem wird als Dirty Reading bezeichnet. Dies ist eine Isolationsstufe mit einem geringeren Isolationsgrad. Sie kann in praktischen Anwendungen viele Probleme verursachen und wird daher im Allgemeinen nicht verwendet.

2. LESEN SIE SICH VERPFLICHTET. Unter der Isolationsstufe von RC tritt kein Dirty-Read-Problem auf. Die von Transaktion A an den Daten vorgenommenen Änderungen sind nach der Übermittlung für Transaktion B sichtbar. Wenn beispielsweise Transaktion B geöffnet wird, werden Daten 1 gelesen, dann wird Transaktion A geöffnet, die Daten werden in 2 geändert, übermittelt und B liest Wenn Sie die Daten erneut lesen, werden die neuesten Daten gelesen. 2. Unter der Isolationsstufe RC tritt das Problem nicht wiederholbarer Lesevorgänge auf. Diese Isolationsstufe ist die Standardisolationsstufe für viele Datenbanken.

3. WIEDERHOLBARES LESEN. Unter der Isolationsstufe RR tritt kein nicht wiederholbares Leseproblem auf. Nachdem die von Transaktion A an den Daten vorgenommenen Änderungen übermittelt wurden, sind sie für Transaktionen, die vor Transaktion A gestartet wurden, nicht sichtbar. Wenn beispielsweise Transaktion B geöffnet wird, werden Daten 1 gelesen. Dann wird Transaktion A geöffnet, die Daten werden in 2 geändert, und B liest die Daten erneut und kann immer noch nur 1 lesen. Unter der Isolationsstufe von RR tritt das Problem des Phantomlesens auf. Die Bedeutung des Phantomlesens besteht darin, dass, wenn eine Transaktion einen Wert in einem bestimmten Bereich liest und eine andere Transaktion einen neuen Datensatz in diesen Bereich einfügt, die vorherige Transaktion den Wert in diesem Bereich erneut liest und neu eingefügte Daten liest. Die Standardisolationsstufe von MySQL ist RR, aber die Gap-Sperre der InnoDB-Engine von MySQL löst das Problem des Phantom-Lesevorgangs erfolgreich.

4.SERIALIZABLE (serialisierbar). Serialisierbar ist die höchste Isolationsstufe. Diese Isolationsstufe erzwingt die serielle Ausführung aller Dinge. Auf dieser Isolationsstufe ist jede gelesene Datenzeile gesperrt, was zu einer großen Anzahl von Sperrenerfassungsproblemen und der schlechtesten Leistung führt.

Um das Verständnis der vier Isolationsstufen zu erleichtern, finden Sie hier ein Beispiel. Wie in Abbildung 1 dargestellt, werden Transaktion A und Transaktion B nacheinander geöffnet und Daten 1 werden mehrmals aktualisiert. Vier Bösewichte starten Transaktionen zu unterschiedlichen Zeiten. Welche Werte können sie in Daten 1 sehen?

Bild 1

Der erste Bösewicht kann alles zwischen 1 und 20 lesen. Denn unter der Isolationsstufe des nicht festgeschriebenen Lesevorgangs sind Änderungen an Daten durch andere Transaktionen auch für die aktuelle Transaktion sichtbar. Der zweite Bösewicht kann 1, 10 und 20 lesen. Er kann nur Daten lesen, die von anderen Transaktionen übermittelt wurden. Die vom dritten Bösewicht gelesenen Daten hängen vom Zeitpunkt ab, zu dem die eigene Transaktion gestartet wird. Der beim Start der Transaktion gelesene Wert ist der Wert, der vor dem Festschreiben der Transaktion gelesen wird. Der vierte Bösewicht kann nur Daten lesen, wenn er zwischen A-Ende und B-Start eingeschaltet ist. Die Daten können jedoch nicht während der Ausführung von Transaktion A und Transaktion B gelesen werden. Da der vierte Bösewicht beim Lesen von Daten gesperrt werden muss, wird während der Ausführung der Transaktionen A und B die Schreibsperre der Daten belegt, sodass der vierte Bösewicht auf die Sperre warten muss.

Abbildung 2 listet die Probleme auf, mit denen verschiedene Isolationsstufen konfrontiert sind.

Bild 2

Je höher die Isolationsstufe, desto höher ist natürlich auch der Ressourcenverbrauch (Sperren) und desto geringer ist die Parallelitätsleistung. Genauer gesagt gibt es unter der serialisierbaren Isolationsstufe keine Parallelität.

Bild 3

Transaktionen in MySql

Die Implementierung von Transaktionen basiert auf der Datenbankspeicher-Engine. Verschiedene Speicher-Engines bieten unterschiedliche Ebenen der Unterstützung für Transaktionen. Zu den Speicher-Engines, die Transaktionen in MySQL unterstützen, gehören innoDB und NDB. innoDB ist die Standardspeicher-Engine von MySQL. Die Standardisolationsstufe ist RR und geht noch einen Schritt weiter als die Isolationsstufe von RR. Sie löst das Problem des nicht wiederholbaren Lesens durch die Parallelitätskontrolle mehrerer Versionen . MVCC, Multiversion Concurrency Control), Hinzufügen von Lückensperren (dh Parallelitätskontrolle), um das Phantomleseproblem zu lösen. Daher erreicht die RR-Isolationsstufe von innoDB tatsächlich den Effekt der Serialisierungsstufe und behält eine relativ gute Parallelitätsleistung bei.

Die Isolierung von Transaktionen wird durch Sperren erreicht, während die Atomarität, Konsistenz und Haltbarkeit von Transaktionen durch Transaktionsprotokolle erreicht werden. Wenn es um Transaktionsprotokolle geht, kann ich nur „Wiederholen“ und „Rückgängig“ sagen.

1.Redo-Protokoll

In der innoDB-Speicher-Engine werden Transaktionsprotokolle durch Redo-Protokolle und den Protokollpuffer (InnoDB-Protokollpuffer) der innoDB-Speicher-Engine implementiert. Wenn eine Transaktion gestartet wird, werden die Vorgänge in der Transaktion zunächst in den Protokollpuffer der Speicher-Engine geschrieben. Bevor die Transaktion festgeschrieben wird, müssen diese gepufferten Protokolle aus Gründen der Persistenz vorab auf die Festplatte geleert werden „Zuerst protokollieren“ „(Write-Ahead-Protokollierung). Nachdem die Transaktion festgeschrieben wurde, werden die im Pufferpool zugeordneten Datendateien langsam auf der Festplatte aktualisiert. Wenn zu diesem Zeitpunkt die Datenbank abstürzt oder ausgefallen ist und das System zur Wiederherstellung neu gestartet wird, kann die Datenbank basierend auf den im Redo-Protokoll aufgezeichneten Protokollen in den Zustand vor dem Absturz zurückversetzt werden. Abhängig von der Wiederherstellungsstrategie können nicht abgeschlossene Transaktionen weiterhin übermittelt oder rückgängig gemacht werden.

Beim Systemstart wurde ein kontinuierlicher Speicherplatz für das Redo-Log zugewiesen.

Das Redo-Log wird in einer sequentiellen Anhängemethode aufgezeichnet und verbessert die Leistung durch sequentielle E/A. Alle Transaktionen teilen sich den Speicherplatz des Redo-Logs. Ihre Redo-Logs werden abwechselnd entsprechend der Ausführungsreihenfolge der Anweisungen aufgezeichnet. Hier ist ein einfaches Beispiel: Datensatz 1:

Datensatz 2:

Datensatz 3:

Datensatz 4:

Datensatz 5:

2.Protokoll rückgängig machen

Das Rückgängig-Protokoll dient hauptsächlich dem Transaktions-Rollback. Während des Transaktionsausführungsprozesses wird zusätzlich zum Redo-Log auch eine gewisse Menge an Undo-Log aufgezeichnet. Das Rückgängig-Protokoll zeichnet den Status der Daten vor jedem Vorgang auf. Wenn während der Transaktionsausführung ein Rollback erforderlich ist, kann der Rollback-Vorgang basierend auf dem Rückgängig-Protokoll durchgeführt werden. Das Rollback einer einzelnen Transaktion führt nur zu einem Rollback der von der aktuellen Transaktion ausgeführten Vorgänge und hat keinen Einfluss auf die von anderen Transaktionen ausgeführten Vorgänge.

Das Folgende ist der vereinfachte Prozess zum Rückgängigmachen von Redo-Transaktionen

Angenommen, es gibt zwei Werte, A und B, mit den Werten 1 und 2

1. Transaktion starten;

2. Notieren Sie A=1, um das Protokoll rückgängig zu machen;

3. Aktualisierung A = 3;

4. Zeichnen Sie A=3 auf, um das Protokoll zu wiederholen 5. Nehmen Sie B=2 auf, um das Protokoll rückgängig zu machen

6. Aktualisierung B = 4; 7. Datensatz B = 4 zum Wiederherstellen des Protokolls

8. Redo-Log auf die Festplatte schreiben

9. Commit

Wenn das System bei Schritt 1–8 ausfällt und die Transaktion nicht festgeschrieben wird, hat die Transaktion keine Auswirkungen auf die Daten auf der Festplatte. Wenn es zwischen 8 und 9 ausfällt, können Sie nach der Wiederherstellung ein Rollback durchführen oder die Transaktionsübermittlung fortsetzen, da das Redo-Protokoll zu diesem Zeitpunkt beibehalten wurde. Wenn das System nach 9 abstürzt und die geänderten Daten in der Speicherzuordnung nicht auf die Festplatte zurückgespült werden, können die Daten nach der Wiederherstellung des Systems gemäß dem Redo-Protokoll wieder auf die Festplatte zurückgespült werden.

Das Redo-Log garantiert also tatsächlich die Dauerhaftigkeit und Konsistenz von Transaktionen, während das Undo-Log die Atomizität von Transaktionen garantiert.

Verteilte Transaktionen

Es gibt viele Möglichkeiten, verteilte Transaktionen zu implementieren. Sie können die native Transaktionsunterstützung von innoDB verwenden oder Nachrichtenwarteschlangen verwenden, um die ultimative Konsistenz verteilter Transaktionen zu erreichen. Hier sprechen wir hauptsächlich über die Unterstützung verteilter Transaktionen durch innoDB.

Wie in der Abbildung gezeigt, ist das verteilte Transaktionsmodell von MySQL. Das Modell ist in drei Teile unterteilt: Anwendung (AP), Ressourcenmanager (RM) und Transaktionsmanager (TM).

Die Anwendung definiert die Grenzen der Transaktion und gibt an, welche Transaktionen durchgeführt werden müssen

Der Ressourcenmanager bietet eine Methode für den Zugriff auf Transaktionen. Normalerweise ist eine Datenbank ein Ressourcenmanager

Der Transaktionsmanager koordiniert und beteiligt sich an verschiedenen Transaktionen der globalen Transaktion.

Verteilte Transaktionen verwenden eine zweiphasige Commit-Methode. In der ersten Phase beginnen alle Transaktionsknoten mit der Vorbereitung und teilen dem Transaktionsmanager mit, dass sie bereit sind. Der Transaktionsmanager der zweiten Stufe teilt jedem Knoten mit, ob ein Commit oder ein Rollback durchgeführt werden soll. Wenn ein Knoten ausfällt, müssen alle globalen Knoten zurückgesetzt werden, um die Atomizität der Transaktion sicherzustellen.

Zusammenfassung

Wann müssen Sie Transaktionen verwenden? Ich denke, solange das Unternehmen ACID-Szenarien erfüllen muss, ist Transaktionsunterstützung erforderlich. Gerade in Ordersystemen und Bankensystemen sind Transaktionen unverzichtbar. In diesem Artikel werden hauptsächlich die Merkmale von Transaktionen und die Unterstützung von MySQL innoDB für Transaktionen vorgestellt. Es gibt weitaus mehr Wissen über Angelegenheiten, als in dem Artikel angegeben wird. Ich hoffe, die Leser verzeihen mir etwaige Mängel.