Ich habe in letzter Zeit an Auftragsprojekten gearbeitet und 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 Folgendes tun:
1. Überprüfen Sie den Kontostand von A.
2. Ziehen Sie 500 Yuan vom Konto von A ab 500 Yuan hinzugefügt;
Nach dem normalen Vorgang wurden 500 Yuan von Konto A abgebucht und 500 Yuan auf Konto B eingezahlt. 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 tatsächlichen Situationen wird jedoch der Grad der Interaktion zwischen Transaktionen durch die Isolationsstufe beeinflusst. Einzelheiten dazu folgen später im Artikel.
4. D(Haltbarkeit) Persistenz. 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? Unter dem Isolationsgrad einer Transaktion versteht man, wie „egoistisch“ eine Transaktion ist, was die Sichtbarkeit zwischen Transaktionen definiert. Die Isolationsstufen sind in die folgenden Typen unterteilt:
1.READ UNCOMMITTED (nicht festgeschriebenes Lesen). Unter der Isolationsstufe von RU 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 häufig verwendet.
2. LESEN SIE SICH VERPFLICHTET. Unter der Isolationsstufe 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.REPEATABLE READ (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 irgendwo zwischen 1 und 20 lesen. Denn unter der Isolationsstufe des nicht festgeschriebenen Lesens sind Datenänderungen 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 seine 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 Daten nur lesen, wenn sie zwischen A Ende und B-Start geöffnet werden. 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.
Abbildung 2
Offensichtlich ist der Ressourcenverbrauch (Sperren) umso höher, je höher die Isolationsstufe ist, sodass die Parallelität geringer ist. Genauer gesagt gibt es unter der serialisierbaren Isolationsstufe keine Parallelität.
Abbildung 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 wird das Transaktionsprotokoll über das Redo-Protokoll 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 die Leistung wird durch sequentielle E/A verbessert. Alle Transaktionen teilen sich den Speicherplatz des Redo-Logs, und ihre Redo-Logs werden abwechselnd entsprechend der Ausführungsreihenfolge der Anweisungen gemeinsam aufgezeichnet. Als einfaches Beispiel:
Datensatz 1:
Datensatz 2:
Datensatz 3:
Datensatz 4:
Datensatz 5:
2.Undo-Log
Undo-Log dient hauptsächlich dem Rollback von Transaktionen. 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 Vorgang zum Rückgängigmachen und Wiederherstellen einer Transaktion.
Angenommen, es gibt zwei Werte, A und B, mit den Werten 1 und 2.
1 Transaktion starten ;
2. Zeichnen Sie A=1 auf, um das Protokoll rückgängig zu machen;
3. Aktualisieren Sie A = 3;
4. Nehmen Sie A=3 auf, um das Protokoll zu wiederholen;
5. Rekord B = 2, um das Protokoll rückgängig zu machen;
7 Redo-Protokoll Auf Festplatte aktualisieren
9. Festschreiben
Wenn das System bei Schritt 1-8 ausfällt und die Transaktion nicht festgeschrieben wird, hat die Transaktion keine Auswirkungen auf die Daten auf dem Scheibe. 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 verteilte Transaktionen zu implementieren . Endgültige Konsistenz der Transaktionen. 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 stellt Methoden für den Zugriff auf Transaktionen bereit
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, dass die Leser mir etwaige Mängel verzeihen.
Das obige ist der detaillierte Inhalt vonDetaillierte grafische Erläuterung der Transaktionen in MySql. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!
