Detaillierte Erläuterung des Implementierungsprinzips von ACID-Transaktionen in MySQL

Einführung

Beginnen wir wie immer mit einer Szene~

Interviewer: „Kennen Sie die vier Merkmale von Transaktionen?“
Sie: „Ja, ACID, Atomarität, Konsistenz, Isolation, Haltbarkeit!“
Interviewer: „Sie verwenden eine MySQL-Datenbank, richtig? Können Sie kurz erklären, wie diese vier Funktionen in InnoDB implementiert sind?“
Sie: „Ich weiß nur, wie Isolation funktioniert, balabala~~“
Interviewer: „Sie sollten zurückgehen und auf die Benachrichtigung warten~“

Okay, zurück zum Thema. Viele Menschen verstehen die vier Hauptmerkmale von Transaktionen – Atomarität, Konsistenz, Isolation und Dauerhaftigkeit –. Aber gehen wir etwas konkreter vor. Wie werden diese vier Features in der Datenbank implementiert? Dann können nur wenige Menschen diese Frage beantworten. Daher konzentriert sich dieser Artikel auf die Implementierungsprinzipien der vier Hauptfunktionen in MySQL.

Text

Nehmen wir das Beispiel der Überweisung von 50 Yuan von Konto A auf Konto B, um die vier Hauptmerkmale von ACID zu veranschaulichen.

Atomarität

Atomarität bedeutet per Definition, dass eine Transaktion eine unteilbare Arbeitseinheit ist, in der entweder alle Vorgänge ausgeführt werden oder keiner. Das heißt, entweder die Übertragung ist erfolgreich oder sie schlägt fehl, einen Mittelzustand gibt es nicht!

Was passiert, wenn Atomarität nicht garantiert werden kann?

OK, es kommt zu einer Dateninkonsistenz, von Konto A werden 50 Yuan abgezogen, während der Betrag von Konto B um 50 Yuan erhöht wird, und der Vorgang schlägt fehl. Das System verliert grundlos 50 Yuan ~

Isolierung

Isolation bedeutet per Definition, dass bei der gleichzeitigen Ausführung mehrerer Transaktionen die Vorgänge innerhalb der Transaktion von anderen Transaktionen isoliert sind und die gleichzeitig ausgeführten Transaktionen sich nicht gegenseitig stören können.

Was passiert, wenn die Isolierung nicht gewährleistet werden kann?

OK, nehmen wir an, auf Konto A befinden sich 200 Yuan und auf Konto B 0 Yuan. Von Konto A wurden zweimal Gelder auf Konto B überwiesen, und zwar in einer Gesamtsumme von 50 Yuan, die jeweils in zwei Transaktionen ausgeführt wurden. Wenn die Isolierung nicht gewährleistet werden kann, können folgende Situationen eintreten

Wie in der Abbildung gezeigt, ist die Isolierung nicht gewährleistet, A zieht zweimal Geld ab, B fügt jedoch nur einmal Geld hinzu, 50 Yuan verschwinden aus dem Nichts und es kommt weiterhin zu Dateninkonsistenzen!

PS: Aufmerksame Leser haben möglicherweise entdeckt, dass MySQL zur Lösung von Isolationsproblemen auf Sperren angewiesen ist. Nun, wir werden es später erklären.

Persistenz

Dauerhaftigkeit bedeutet per Definition, dass die Änderungen an einer Transaktion in der Datenbank dauerhaft sein sollten, sobald sie festgeschrieben ist. Nachfolgende andere Operationen oder Störungen sollten hierauf keinen Einfluss haben.

Was passiert, wenn die Persistenz nicht garantiert werden kann?

Um das Problem inkonsistenter CPU- und Festplattengeschwindigkeiten zu lösen, lädt MySQL in MySQL die Daten auf der Festplatte in den Speicher, bearbeitet den Speicher und schreibt sie dann wieder auf die Festplatte. Nehmen wir an, der Server stürzt zu diesem Zeitpunkt ab. Alle im Speicher geänderten Daten gehen verloren und die Persistenz kann nicht garantiert werden.

Stellen Sie sich vor, das System meldet Ihnen, dass die Überweisung erfolgreich war. Sie stellen jedoch fest, dass sich der Betrag überhaupt nicht geändert hat. Zu diesem Zeitpunkt befinden sich die Daten in einem ungültigen Zustand. Wir betrachten diesen Zustand als Dateninkonsistenz.

Konsistenz

Konsistenz bedeutet per Definition, dass sich die Daten vor und nach der Ausführung der Transaktion in einem gültigen Zustand befinden. Dieser Zustand ist eher semantischer als syntaktischer Natur.
Wie ist also der rechtliche Status der Daten?

ok, dieser Zustand wird als legaler Zustand bezeichnet, wenn er die vorgegebenen Einschränkungen erfüllt. Einfacher ausgedrückt: Dieser Zustand wird von Ihnen definiert. Ist dieser Zustand erfüllt, sind die Daten konsistent. Ist dieser Zustand nicht erfüllt, sind die Daten inkonsistent!

Was passiert, wenn die Konsistenz nicht gewährleistet werden kann?

Beispiel 1: Auf Konto A sind 200 Yuan vorhanden und 300 Yuan werden abgehoben. Zu diesem Zeitpunkt beträgt der Kontostand von Konto A -100 Yuan. Sie werden natürlich feststellen, dass die Daten zu diesem Zeitpunkt inkonsistent sind. Warum? Da Sie einen Status definiert haben, muss die Saldospalte größer als 0 sein.

Beispiel 2: Auf Konto A befinden sich 200 Yuan, davon werden 50 Yuan auf Konto B überwiesen. Das Geld auf Konto A wird abgezogen, aber der Saldo auf Konto B erhöht sich aufgrund verschiedener unerwarteter Ereignisse nicht. Sie wissen auch, dass die Daten zum jetzigen Zeitpunkt inkonsistent sind, warum? Weil Sie einen Zustand definiert haben, bei dem das Gleichgewicht von A+B unverändert bleiben muss.

Praktische Antworten

Frage 1: Wie stellt Mysql Konsistenz sicher?

OK, diese Frage kann in zwei Ebenen unterteilt werden.

Auf Datenbankebene gewährleistet die Datenbank Konsistenz durch Atomarität, Isolation und Persistenz. Das heißt, unter den vier Hauptmerkmalen von ACID ist C (Konsistenz) der Zweck, A (Atomizität), I (Isolation) und D (Persistenz) sind Mittel, die von der Datenbank bereitgestellt werden, um die Konsistenz sicherzustellen. Um Konsistenz zu erreichen, muss die Datenbank die drei Hauptmerkmale von AID implementieren. Beispielsweise kann Atomarität nicht garantiert werden und offensichtlich kann auch Konsistenz nicht garantiert werden.

Wenn Sie jedoch absichtlich Code schreiben, der Einschränkungen in einer Transaktion verletzt, kann die Konsistenz nicht garantiert werden. Wenn Ihr Code beispielsweise in Ihrem Überweisungsbeispiel absichtlich kein Geld auf Konto B einzahlt, kann die Konsistenz nicht gewährleistet werden. Daher ist es auch notwendig, die Anwendungsschicht zu berücksichtigen.

Bestimmen Sie auf Anwendungsebene mithilfe des Codes, ob die Datenbankdaten gültig sind, und entscheiden Sie dann, ob ein Rollback oder ein Commit für die Daten durchgeführt werden soll.

Frage 2: Wie stellt Mysql Atomizität sicher?

OK, es soll das Undo-Protokoll von Innodb verwenden.

Das Rückgängigmachen des Protokolls wird als Rollback-Protokoll bezeichnet und ist der Schlüssel zur Erreichung der Atomizität. Wenn eine Transaktion zurückgesetzt wird, können alle erfolgreich ausgeführten SQL-Anweisungen rückgängig gemacht werden. Es muss die entsprechenden Protokollinformationen aufzeichnen, die Sie zurücksetzen möchten.

Zum Beispiel

• (1) Wenn Sie Daten löschen, müssen Sie die Informationen zu diesen Daten aufzeichnen. Fügen Sie beim Zurücksetzen die alten Daten ein.
• (2) Wenn Sie Daten aktualisieren, müssen Sie den alten Wert aufzeichnen. Führen Sie beim Zurücksetzen den Aktualisierungsvorgang basierend auf dem alten Wert durch.
• (3) Beim Einfügen eines Datenelements wird der Primärschlüssel des Datensatzes benötigt. Beim Zurücksetzen wird der Löschvorgang basierend auf dem Primärschlüssel ausgeführt.

Das Undo-Protokoll zeichnet die für das Rollback erforderlichen Informationen auf. Wenn eine Transaktion fehlschlägt oder ein Rollback aufgerufen wird, wodurch die Transaktion zurückgesetzt wird, können die Informationen im Undo-Protokoll verwendet werden, um die Daten auf den Zustand vor der Änderung zurückzusetzen.

ps: Wie sieht das konkrete Undo-Log aus? Das kann man ja in einen Artikel schreiben. Darüber hinaus werden es nicht viele Leute lesen, nachdem sie es aufgeschrieben haben, also halten wir es vorerst einfach.

Frage 3: Wie stellt Mysql Beständigkeit sicher?

OK, es verwendet das Redo-Protokoll von Innodb.

Wie bereits erwähnt, lädt MySQL zuerst die Daten auf der Festplatte in den Speicher, ändert die Daten im Speicher und schreibt sie dann zurück auf die Festplatte. Wenn der Computer zu diesem Zeitpunkt plötzlich abstürzt, gehen die Daten im Speicher verloren.

Wie kann dieses Problem gelöst werden?

Es ist ganz einfach. Schreiben Sie die Daten einfach auf die Festplatte, bevor Sie die Transaktion bestätigen.

Was ist falsch daran, das zu tun?

• Um nur ein Byte auf einer Seite zu ändern, muss die gesamte Seite auf die Festplatte geschrieben werden, was eine Verschwendung von Ressourcen darstellt. Immerhin ist eine Seite 16 KB groß. Wenn Sie nur ein bisschen daran ändern, müssen Sie 16 KB Inhalt auf die Festplatte übertragen, was nicht sinnvoll klingt.
• Schließlich kann das SQL in einer Transaktion die Änderung mehrerer Datenseiten beinhalten, und diese Datenseiten sind möglicherweise nicht benachbart, was zu zufälligen E/A führt. Offensichtlich ist die Geschwindigkeit des zufälligen IO-Vorgangs langsamer.

Daher wurde entschieden, zur Lösung der oben genannten Probleme ein Redo-Log zu verwenden. Wenn Daten geändert werden, wird dies nicht nur im Speicher ausgeführt, sondern auch im Redo-Protokoll aufgezeichnet. Wenn eine Transaktion festgeschrieben wird, wird das Redo-Protokoll auf die Festplatte geschrieben (ein Teil des Redo-Protokolls befindet sich im Speicher und ein Teil auf der Festplatte). Wenn die Datenbank abstürzt und neu gestartet wird, wird der Inhalt des Redo-Protokolls in der Datenbank wiederhergestellt. Anschließend wird basierend auf dem Inhalt des Undo-Protokolls und des Binärprotokolls entschieden, ob ein Rollback oder ein Commit der Daten durchgeführt wird.

Welche Vorteile bietet die Verwendung des Redo-Logs?

Tatsächlich besteht der Vorteil darin, dass das Leeren von Redo-Protokollen auf die Festplatte effizienter ist als das Leeren von Datenseiten auf die Festplatte. Die spezifische Leistung ist wie folgt

• Das Redo-Protokoll ist klein, da es nur aufzeichnet, welche Seite geändert wurde. Es ist also klein und kann schnell gelöscht werden.
• Das Redo-Log wird immer ans Ende angehängt und gehört zum sequentiellen IO. Die Effizienz ist offensichtlich schneller als bei zufälliger E/A.

PS: Wie das Redo-Log im Detail aussieht, möchte ich hier nicht näher erläutern, da der Inhalt zu umfangreich ist.

Frage 4: Wie stellt Mysql die Isolation sicher?

OK, der Sperr- und MVCC-Mechanismus wird verwendet. Nehmen wir zur Veranschaulichung das Beispiel einer Überweisung. Es gibt eine Kontentabelle wie folgt

Tabellenname t_balance

Dabei ist „id“ der Primärschlüssel, „user_id“ der Kontoname und „balance“ der Kontostand. Nehmen wir das Beispiel einer zweimaligen Geldüberweisung, wie in der folgenden Abbildung dargestellt

Bei MVCC (die Abkürzung steht für Multi Version Concurrency Control) weist eine Zeile mit Datensatzdaten mehrere Versionen von Snapshot-Daten auf, und diese Snapshot-Daten befinden sich im Undo-Protokoll.

Wenn eine Transaktion eine Zeile liest, die gelöscht oder aktualisiert wird, wartet der Lesevorgang nicht darauf, dass die Sperre der Zeile aufgehoben wird, sondern liest stattdessen eine Snapshot-Version der Zeile.

Da der MVCC-Mechanismus in Repeatable Read und Read Commited MVCC unterschiedlich ausgedrückt wird, werde ich nicht ins Detail gehen.

Zu beachten ist jedoch, dass eine Transaktion, wenn die Transaktionsisolationsebene auf „Read Committed“ eingestellt ist, Daten lesen kann, die von einer anderen Transaktion festgeschrieben wurden, wodurch die Isolationsanforderung nicht erfüllt wird. Wenn die Transaktionsisolationsebene jedoch „Wiederholbares Lesen“ lautet, ist die Isolation gewährleistet.

Zusammenfassen

In diesem Artikel werden die Implementierungsprinzipien der vier wichtigsten ACID-Merkmale von MySQL-Transaktionen erläutert. Ich hoffe, Sie profitieren davon.

Das ist alles für diesen Artikel. Ich hoffe, dass der Inhalt dieses Artikels für Ihr Studium oder Ihre Arbeit von gewissem Referenzwert ist. Vielen Dank für Ihre Unterstützung von 123WORDPRESS.COM.