Umfassende Analyse von optimistischer Sperre, pessimistischer Sperre und MVCC in MySQL

Vorwort

Bei der tatsächlichen Verwendung der Datenbank stoßen wir häufig auf Situationen, in denen wir nicht möchten, dass Daten gleichzeitig geschrieben oder gelesen werden. Beispielsweise lesen in einem Flash-Sale-Szenario zwei Anfragen gleichzeitig, dass das System noch 1 Artikel auf Lager hat, und aktualisieren den Bestand dann nacheinander auf 0. Dies führt zu einer Überverkaufssituation und der tatsächliche Warenbestand entspricht nicht unseren Aufzeichnungen.

Um Probleme wie Dateninkonsistenz aufgrund von Ressourcenkonkurrenz zu lösen, benötigen wir einen Mechanismus, der den korrekten Zugriff und die korrekte Änderung von Daten gewährleistet. In der Datenbank ist dieser Mechanismus die Datenbank-Parallelitätskontrolle. Unter ihnen sind die optimistische Parallelitätskontrolle, die pessimistische Parallelitätskontrolle und die Mehrversionen-Parallelitätskontrolle die wichtigsten technischen Mittel, die für die Datenbank-Parallelitätskontrolle verwendet werden.

Pessimistische Parallelitätskontrolle

Natur

Wikipedia: In relationalen Datenbankmanagementsystemen ist die pessimistische Parallelitätskontrolle (auch bekannt als „pessimistische Sperrung“, abgekürzt „PCC“) eine Methode der Parallelitätskontrolle. Dadurch wird verhindert, dass durch eine Transaktion Daten in einer Weise geändert werden, die Auswirkungen auf andere Benutzer hat. Wenn eine Transaktion einen Vorgang ausführt, bei dem eine Datenzeile gelesen und eine Sperre angewendet wird, können andere Transaktionen Vorgänge, die mit der Sperre in Konflikt stehen, nur dann ausführen, wenn die Transaktion die Sperre freigibt.

Tatsächlich handelt es sich bei der pessimistischen Sperre, von der wir oft sprechen, nicht um eine tatsächliche Sperre, sondern um eine Idee der Parallelitätskontrolle. Die pessimistische Parallelitätskontrolle ist pessimistisch in Bezug auf Datenänderungen und geht davon aus, dass es unweigerlich zu Konflikten kommt, wenn von außen auf Daten zugegriffen wird. Daher wird bei der Datenverarbeitung eine Sperre verwendet, um die exklusive Nutzung von Ressourcen sicherzustellen.

Der Datenbanksperrmechanismus wird tatsächlich basierend auf der Sichtweise der pessimistischen Parallelitätskontrolle implementiert, und je nach tatsächlicher Verwendung kann die Datenbanksperre in viele Kategorien unterteilt werden. Einzelheiten finden Sie in meinem späteren Artikel.

Durchführung

Der Sperrvorgang der pessimistischen Datenbanksperre läuft wie folgt ab:

Nach dem Starten einer Transaktion beantragen Sie eine bestimmte Art von Sperre für die Daten, die je nach Operationstyp gesperrt werden müssen: beispielsweise eine gemeinsame Zeilensperre. Wenn die Sperre erfolgreich ist, fahren Sie mit den nachfolgenden Operationen fort. Wenn die Daten durch andere Sperren gesperrt wurden und es zu Konflikten mit der jetzt hinzuzufügenden Sperre kommt, schlägt die Sperre fehl (z. B. wurde eine exklusive Sperre hinzugefügt). Zu diesem Zeitpunkt müssen Sie warten, bis andere Sperren freigegeben werden (es kann zu einem Deadlock kommen).
Heben Sie die Sperre auf, nachdem Sie die Transaktion abgeschlossen haben

Für und Wider

Vorteil:

Bei der pessimistischen Parallelitätskontrolle wird eine konservative Strategie verfolgt: „Erst die Sperre erhalten und dann, wenn dies erfolgreich ist, auf die Daten zugreifen.“ Dadurch wird sichergestellt, dass Datenerfassung und -änderung ordnungsgemäß durchgeführt werden, sodass es für den Einsatz in einer Umgebung mit mehr Schreibvorgängen und weniger Lesevorgängen geeignet ist. Natürlich kann durch die Verwendung einer pessimistischen Sperre keine sehr hohe Leistung aufrechterhalten werden, aber unter der Voraussetzung, dass eine optimistische Sperre keine bessere Leistung bieten kann, kann eine pessimistische Sperre die Datensicherheit gewährleisten.

Mangel:
Da Sperren erforderlich sind und es zu Sperrkonflikten oder sogar Deadlocks kommen kann, erhöht die pessimistische Parallelitätskontrolle den System-Overhead, verringert die Systemleistung und reduziert auch die Systemparallelität.

Optimistische Parallelitätskontrolle

Natur

Wikipedia: In relationalen Datenbankmanagementsystemen ist die optimistische Parallelitätskontrolle (auch bekannt als „optimistisches Sperren“, Optimistic Concurrency Control, abgekürzt „OCC“) eine Methode zur Parallelitätskontrolle. Dabei wird davon ausgegangen, dass sich gleichzeitige Transaktionen mehrerer Benutzer während der Verarbeitung nicht gegenseitig beeinflussen und jede Transaktion den von ihr betroffenen Teil der Daten verarbeiten kann, ohne Sperren zu generieren.
Die optimistische Parallelitätssteuerung ist optimistisch in Bezug auf Datenänderungen und geht davon aus, dass externe Vorgänge an Daten selbst in einer parallelen Umgebung im Allgemeinen keine Konflikte verursachen und die Daten daher nicht sperren. Stattdessen prüft jede Transaktion vor dem Senden von Datenaktualisierungen zunächst, ob andere Transaktionen die Daten geändert haben, nachdem die Transaktion die Daten gelesen hat. Wenn die Transaktion durch andere Transaktionen aktualisiert wurde, werden Konfliktinformationen zurückgegeben, sodass der Benutzer entscheiden kann, wie er weiter vorgehen möchte, z. B. durch erneuten Versuch oder Rollback.

Es ist ersichtlich, dass optimistisches Sperren eigentlich keine Sperre ist und nicht einmal Sperren zur Implementierung der Parallelitätskontrolle verwendet. Stattdessen werden andere Methoden verwendet, um zu bestimmen, ob Daten geändert werden können. Optimistisches Sperren ist im Allgemeinen ein vom Benutzer implementierter Sperrmechanismus. Obwohl kein tatsächliches Schloss verwendet wird, kann es einen Sperreffekt erzeugen.

Durchführung

CAS (Compare and Swap) ist ein bekannter sperrenfreier Algorithmus. Sperrenfreie Programmierung bedeutet, eine Variablensynchronisierung zwischen mehreren Threads ohne Verwendung von Sperren zu realisieren, d. h. eine Variablensynchronisierung ohne Blockierung von Threads zu realisieren. Daher wird dies auch als nicht blockierende Synchronisierung bezeichnet. Das Schema zur Implementierung einer nicht blockierenden Synchronisierung wird als „sperrenfreier Programmieralgorithmus“ bezeichnet.

Optimistisches Sperren wird grundsätzlich basierend auf dem CAS-Algorithmus (Compare and Swap) implementiert. Schauen wir uns zunächst den CAS-Prozess an. Der Ablauf einer CAS-Operation kann durch den folgenden C-Code dargestellt werden:

int cas(long *Adresse, long alt, long neu)
{
 /* Wird atomar ausgeführt. */
 if(*Adresse != alt)
  gebe 0 zurück;
 *Adresse = neu;
 Rückgabe 1;
}

CAS hat drei Operanden, den Speicherwert V, den alten erwarteten Wert A und den neuen zu ändernden Wert B. Genau dann, wenn der erwartete Wert A und der Speicherwert V identisch sind, ändern Sie den Speicherwert V in B, andernfalls tun Sie nichts. Der gesamte CAS-Vorgang ist ein atomarer Vorgang und unteilbar.

Die Implementierung der optimistischen Sperre ähnelt dem obigen Prozess, im Wesentlichen in den folgenden Punkten:

• Versionsnummern-Tag: Fügen Sie der Tabelle ein neues Feld hinzu: Version, das zum Speichern der Versionsnummer verwendet wird. Holen Sie sich beim Abrufen der Daten gleichzeitig die Versionsnummer und verwenden Sie dann den folgenden Befehl, um die Daten zu aktualisieren: update xxx set version=version+1,… wobei … version="alte Version" und …. Ob die Aktualisierung erfolgreich war, wird zu diesem Zeitpunkt dadurch bestimmt, dass beurteilt wird, ob die Anzahl der betroffenen Zeilen im zurückgegebenen Ergebnis 0 ist. Wenn die Aktualisierung fehlschlägt, bedeutet dies, dass andere Anforderungen die Daten bereits aktualisiert haben.
• Zeitstempel: Dasselbe wie die Versionsnummer, aber durch den Zeitstempel bestimmt. Im Allgemeinen verfügen viele Datentabellen über ein Aktualisierungszeitfeld. Wenn Sie dieses Feld zur Beurteilung verwenden, müssen Sie kein neues Feld hinzufügen.
• Zu aktualisierende Felder: Wenn kein Zeitstempelfeld vorhanden ist und Sie keine neuen Felder hinzufügen möchten, können Sie die zu aktualisierenden Felder zur Beurteilung heranziehen. Da sich aktualisierte Daten im Allgemeinen ändern, können Sie vor der Aktualisierung den alten Wert des zu aktualisierenden Felds mit dem aktuellen Wert der Datenbank vergleichen. Wenn sich nichts ändert, aktualisieren Sie es.
• Alle Feldmarkierungen: Alle Felder der Datentabelle werden zur Beurteilung herangezogen. Dies entspricht dem Sperren nicht nur einiger Felder, sondern der gesamten Datenzeile. Solange sich die Daten in dieser Zeile ändern, werden sie nicht aktualisiert.
  

Für und Wider

Vorteil:

Bei der optimistischen Parallelitätssteuerung kommt es nicht zu tatsächlichen Sperren, sodass kein zusätzlicher Overhead entsteht und Deadlock-Probleme unwahrscheinlich sind. Sie eignet sich für parallele Szenarien mit mehr Lese- und weniger Schreibvorgängen. Da kein zusätzlicher Overhead entsteht, kann die Leistung der Datenbank erheblich verbessert werden.

Mangel:
Die optimistische Parallelitätssteuerung ist nicht für parallele Szenarien mit mehr Schreib- als Lesevorgängen geeignet, da es zu vielen Schreibkonflikten kommt, die zu mehreren Wartezeiten und Wiederholungsversuchen beim Schreiben von Daten führen. In diesem Fall ist der Overhead tatsächlich höher als bei der pessimistischen Sperre. Darüber hinaus ist die Geschäftslogik der optimistischen Sperre komplizierter als die der pessimistischen Sperre. Die Geschäftslogik muss Fehler und Wartezeiten auf Wiederholungsversuche berücksichtigen und kann direkte Änderungen an der Datenbank durch andere Drittsysteme nicht vermeiden.

Steuerung der Parallelität mehrerer Versionen

Natur

Wikipedia: Multiversion Concurrency Control (MCC oder MVCC) ist eine Art der Parallelitätskontrolle, die häufig in Datenbankverwaltungssystemen verwendet wird und auch in Programmiersprachen zur Implementierung von transaktionalem Speicher verwendet wird.

Sowohl die optimistische als auch die pessimistische Parallelitätskontrolle gewährleisten die Serialisierbarkeit von Transaktionen, indem sie Konkurrenzbedingungen zwischen Transaktionen durch Verzögerung oder Beendigung entsprechender Transaktionen lösen. Obwohl die beiden vorherigen Parallelitätskontrollmechanismen das Problem der Serialisierbarkeit gleichzeitiger Transaktionen tatsächlich grundsätzlich lösen können, lösen sie tatsächlich das Problem von Schreibkonflikten. Der Unterschied zwischen den beiden liegt in den unterschiedlichen Graden des Optimismus in Bezug auf Schreibkonflikte (pessimistische Sperren können auch Lese-/Schreibkonflikte lösen, die Leistung ist jedoch durchschnittlich). In der Praxis gibt es in der Datenbank Leseanforderungen, die Schreibanforderungen um ein Vielfaches übersteigen. Wenn wir das Problem der Lese- und Schreibparallelität lösen können, können wir die Leseleistung der Datenbank erheblich verbessern. Genau das kann die Multiversion-Parallelitätskontrolle leisten.

Im Gegensatz zur pessimistischen und optimistischen Parallelitätskontrolle ist MVCC darauf ausgelegt, das Problem mehrerer, langfristiger Lesevorgänge und dadurch bedingter Schreibausfälle aufgrund von Lese-/Schreibsperren zu lösen, also das Problem von Lese-/Schreibkonflikten. MVCC kann in Verbindung mit jedem der beiden vorherigen Mechanismen verwendet werden, um die Leseleistung der Datenbank zu verbessern.

Das pessimistische Sperren von Datenbanken basiert auf der Überlegung, die Parallelitätsleistung zu verbessern, und implementiert im Allgemeinen gleichzeitig eine Mehrversionen-Parallelitätskontrolle. Nicht nur MySQL, sondern auch andere Datenbanksysteme, darunter Oracle, PostgreSQL usw., haben MVCC implementiert, aber ihre Implementierungsmechanismen sind unterschiedlich, da MVCC keinen einheitlichen Implementierungsstandard hat.

Im Allgemeinen ist das Aufkommen von MVCC eine von der Datenbank vorgeschlagene Lösung, da sie aufgrund der geringen Leistung mit der Verwendung pessimistischer Sperren zur Lösung des Lese-/Schreibkonfliktproblems unzufrieden ist.

Durchführung

MVCC wird implementiert, indem zu einem bestimmten Zeitpunkt ein Snapshot der Daten gespeichert wird. Die von jeder Transaktion gelesenen Datenelemente sind ein historischer Snapshot, der als Snapshot-Lesevorgang bezeichnet wird. Im Gegensatz zum aktuellen Lesevorgang sind die vom Snapshot-Lesevorgang gelesenen Daten möglicherweise nicht die neuesten, aber die Snapshot-Isolation stellt sicher, dass die von der gesamten Transaktion gesehenen Daten den Datenstatus beim Start aufweisen. Ein Schreibvorgang überschreibt kein vorhandenes Datenelement, sondern erstellt eine neue Version, die erst sichtbar wird, wenn die Transaktion festgeschrieben wird.

Aktueller Lesevorgang und Snapshot-Lesen

Was sind aktuelles Lesen und Snapshot-Lesen in MySQL InnoDB?

Aktuelle Lesevorgänge wie Auswahlsperre im Freigabemodus (gemeinsame Sperre), Auswahl zum Aktualisieren, Aktualisieren, Einfügen, Löschen (exklusive Sperre) sind alles aktuelle Lesevorgänge. Warum werden sie aktuelle Lesevorgänge genannt? Das heißt, es liest die neueste Version des Datensatzes. Beim Lesen muss sichergestellt werden, dass andere gleichzeitige Transaktionen den aktuellen Datensatz nicht ändern können und der gelesene Datensatz gesperrt wird.

Snapshot-Lesevorgänge sind wie Auswahlvorgänge ohne Sperren, also nicht blockierende Lesevorgänge ohne Sperren. Die Voraussetzung für Snapshot-Lesevorgänge ist, dass die Isolationsebene nicht aus nicht festgeschriebenen Lesevorgängen oder Serialisierungsebenen besteht, da bei nicht festgeschriebenen Lesevorgängen immer die neuesten Datenzeilen gelesen werden und nicht die Datenzeilen, die der aktuellen Transaktionsversion entsprechen. Durch die Serialisierung werden alle gelesenen Zeilen gesperrt.

Für und Wider

MVCC ermöglicht die meisten Lesevorgänge ohne Sperren. Dieses Design vereinfacht das Lesen von Daten, bietet eine gute Leistung und stellt sicher, dass nur Zeilen gelesen werden, die die Kriterien erfüllen. Der Nachteil besteht darin, dass jede Datensatzzeile zusätzlichen Speicherplatz, mehr Zeilenprüfarbeit und einige zusätzliche Wartungsarbeiten erfordert.

Anwendbare Szenarien

Pessimistische Sperre

Die Sperren-Parallelitätskontrolle, die zum Lösen von Lese-/Schreibkonflikten und Schreib-/Schreibkonflikten verwendet wird, eignet sich für Situationen, in denen mehr Schreibvorgänge als Lesevorgänge und schwerwiegende Schreibkonflikte auftreten. Da pessimistische Sperren beim Lesen von Daten gesperrt werden, erfordern Szenarien mit mehr Lesevorgängen häufiges Sperren und viel Wartezeit. Bei schwerwiegenden Schreibkonflikten kann die Verwendung pessimistischer Sperren die Datenkonsistenz sicherstellen. Hohe Anforderungen an die Datenkonsistenz können Probleme wie Dirty Reads, Phantom Reads, nicht wiederholbare Lesevorgänge, Verlust von Updates erster Klasse und Verlust von Updates zweiter Klasse lösen.

Optimistisches Sperren

Die sperrenfreie Parallelitätssteuerung zum Lösen von Schreib-Schreib-Konflikten eignet sich für Situationen, in denen mehr Lese- als Schreibvorgänge stattfinden, denn wenn eine große Anzahl von Schreibvorgängen stattfindet, steigt die Möglichkeit von Schreibkonflikten und die Geschäftsschicht muss ständig neue Versuche unternehmen, was die Systemleistung erheblich reduziert. Die Anforderungen an die Datenkonsistenz sind nicht hoch, aber eine sehr hohe Reaktionsgeschwindigkeit ist erforderlich. Es kann keine Dirty Reads, Phantom Reads und nicht wiederholbare Lesevorgänge lösen, aber es kann das Problem des Updateverlusts lösen.

MVCC

Die sperrenfreie Parallelitätskontrolle, die Lese-/Schreibkonflikte löst, wird mit den beiden oben genannten kombiniert, um deren Leseleistung zu verbessern.

Das Obige ist der detaillierte Inhalt der umfassenden Analyse von optimistischem Sperren, pessimistischem Sperren und MVCC in MySQL. Weitere Informationen zu optimistischem Sperren, pessimistischem Sperren und MVCC in MySQL finden Sie in den anderen verwandten Artikeln auf 123WORDPRESS.COM!