Was ist das Prinzip des optimistischen Lock-Deduction-Inventars in MySQL?

1 Grundkenntnisse

Das Abbuchen von Lagerbeständen ist ein sehr kritischer Vorgang im E-Commerce-System, beispielsweise im Flash Verkaufssystem Achten Sie darauf, Überverkaufssituationen zu vermeiden. Wenn ein Händler 100 Stück Lagerbestand anlegt, am Ende aber 1.000 Stück verkauft, führt dies zu finanziellen Verlusten. Beim Abzug von Lagerbeständen wird im Allgemeinen die folgende Aussage verwendet:

udpate goods set stock = stock - #{acquire} 
where sku_id = #{skuId} and stock - #{acquire} >= 0

Lassen Sie uns analysieren, wie diese Aussage wirksam verhindern kann, dass Lagerbestände überverkauft werden, um die Lagerressourcen zu schützen. In der Demonstration dieses Artikels verwenden wir die MySQL Innodb-Engine und setzen die Isolationsstufe auf wiederholbares Lesen.

1.1 Gemeinsame Sperre und exklusive Sperre

Die gemeinsame Sperre (Share Lock) wird auch als Lesesperre bezeichnet. Die Anweisung zum Implementieren der gemeinsamen Sperre lautet wie folgt:

select lock in share mode

#🎜🎜 #Exklusive Sperre (exklusive Sperre) wird auch als Schreibsperre bezeichnet. Die exklusive Sperranweisung lautet wie folgt:

select for update
update
delete
insert

Die Kompatibilitätsbeziehung zwischen gemeinsamer Sperre und exklusiver Sperre ist wie folgt:

Wir analysieren die obige Kompatibilitätsbeziehung anhand von Beispielen. Erstellen Sie zunächst eine Testtabelle und schreiben Sie die Testdaten:

CREATE TABLE `test_account` (
  `id` bigint(20) NOT NULL,
  `name` varchar(20) DEFAULT NULL,
  `account` bigint(20) DEFAULT NULL,
  `version` bigint(20) DEFAULT NULL,
  PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

insert  into `test_account`(`id`,`name`,`account`,`version`) values (1,'A',100,1);
insert  into `test_account`(`id`,`name`,`account`,`version`) values (2,'B',200,1);
insert  into `test_account`(`id`,`name`,`account`,`version`) values (3,'C',300,1);

(1) Lesekompatibel

Gemeinsame Sperren sind mit gemeinsam genutzten Sperren kompatibel. Im folgenden Beispiel führt Sitzung1 die Abfrage bei t3 und Sitzung2 die Abfrage bei t4 aus, um die erwarteten Ergebnisse zu erhalten: # ?? Sperren, im folgenden Beispiel fügt Sitzung1 zum Zeitpunkt t3 eine gemeinsame Sperre hinzu, und das Ergebnis kann korrekt gelesen werden, aber Sitzung2 versucht zum Zeitpunkt t4, eine exklusive Sperre hinzuzufügen, aber die Sperre ist zu diesem Zeitpunkt von Sitzung1 belegt, und Sitzung2 muss dies tun Warten Sie. Wenn Sitzung1 die Sperre längere Zeit nicht aufhebt, löst Sitzung2 eine Ausnahme wegen Sperrzeitüberschreitung aus: gegenseitiger Ausschluss

Exklusive Sperre Gegenseitig ausschließend mit der exklusiven Sperre Im folgenden Beispiel fügt Sitzung1 eine exklusive Sperre zum Zeitpunkt t3 hinzu, und Sitzung2 versucht dies jedoch korrekt Fügen Sie zum Zeitpunkt t4 eine exklusive Sperre hinzu, aber die Sperre ist zu diesem Zeitpunkt von Sitzung1 belegt und Sitzung2 muss warten. Wenn Sitzung1 die Sperre längere Zeit nicht aufhebt, löst Sitzung2 eine Sperrzeitüberschreitungsausnahme aus: # 🎜🎜#

1.2 Aktuelle Lese- und Snapshot-Lesevorgänge#🎜🎜 #Die Implementierung der MySQL Innodb-Speicher-Engine basiert auf dem Multiversions-Parallelitätskontrollprotokoll MVCC. In der MVCC-Parallelitätskontrolle Lesevorgänge können in Snapshot-Lesevorgänge und aktuelle Lesevorgänge unterteilt werden.

Das Lesen des Snapshots erfordert keine Sperre. Gelesen wird die sichtbare Version des Datensatzes, bei der es sich möglicherweise um eine historische Version handelt. Analog zu einem Bestell-Snapshot bleibt der Bestell-Snapshot unverändert, auch wenn sich der Preis des Produkts ändert, nachdem der Benutzer die Bestellung aufgegeben hat. Die aktuelle Leseanweisung wird wie folgt implementiert:

select

Um die neueste Version des Datensatzes zu lesen, ohne dass er durch andere Transaktionen geändert wird, muss der aktuelle Datensatz gesperrt werden. Die Implementierung der aktuellen Leseanweisung lautet wie folgt:

select lock in share mode
select for update
update
delete
insert

Wir analysieren den Snapshot-Lesevorgang anhand eines Beispiels. Sitzung2 hat den Datensatz bei t4 geändert und ihn bei t5 übermittelt t6. Der Lesevorgang ist das Ergebnis 100 zu Beginn dieser Transaktion. Der aktuelle Lesevorgang wurde zum Zeitpunkt t7 durchgeführt und die neueste Version des Datensatzes 101 wurde gelesen:

#🎜 🎜#

Der aktuelle Lesevorgang ist Wie ist es? Nehmen wir Update als Beispiel, um den aktuellen Lesevorgang zu analysieren:

Wenn eine Programminstanz zum ersten Mal eine aktuelle Leseanforderung ausgibt, gibt die Speicher-Engine die zurück Die erste, die die Where-Bedingung erfüllt, zeichnet auf und sperrt sie. Anschließend gibt die Programminstanz eine Aktualisierungsanforderung aus, und der Speicher bewirkt, dass der Vorgang abgeschlossen wird und die Antwort erfolgreich ist. Nacheinander ausführen, bis alle Datensätze ausgeführt wurden, die die Where-Bedingung erfüllen.

Hier nehmen wir einige Erweiterungen vor. Die RR-Ebene bietet zwei Mechanismen, um Phantomleseprobleme zu vermeiden: Die erste Methode ist das Snapshot-Lesen, das den Snapshot liest, wenn die aktuelle Transaktion gestartet wird. Eine Methode für aktuelle Lesevorgänge besteht darin, den Next-Key-Lock-Mechanismus zu verwenden, um Phantom-Lesevorgänge zu verhindern.

2 Optimistisches Sperrprinzip

Wir integrieren das obige Wissen durch eine Frage: Es gibt zwei Threads, die die folgende Anweisung gleichzeitig ausführen. Bitte fragen Sie nach dem Kontowert des Datensatz-ID=1 Wird der Betrag zweimal erfolgreich abgezogen?

update test_account set account = account - 100, version = version + 1 
where id = 1 and version = 1

Die obige Aussage verwendet optimistisches Sperren. Wir wissen, dass optimistisches Sperren nicht darin besteht, zweimal abzuziehen, aber es muss dabei mit dem Wissen aus Kapitel 1 kombiniert werden . Weitere Analyse:

t2 Sitzung1 und Sitzung2 führen gleichzeitig Aktualisierungsvorgänge aus, da durch das Update eine exklusive Sperre hinzugefügt wird erfolgreich: Sitzung1 ist erfolgreich und Sitzung2 blockiert und wartet auf die Freigabe der exklusiven Sperre.

Zum Zeitpunkt t3 schreibt Sitzung1 die Transaktion fest und gibt die exklusive Sperre frei. Zu diesem Zeitpunkt erhält Sitzung2 die Sperre für das aktuelle Lesen, aber zu diesem Zeitpunkt hat sich der Versionswert des Datensatzes mit der ID = 1 in 2 geändert. Die ausgeführte Anweisung Die zu aktualisierenden Daten können nicht abgefragt werden, daher erfolgt keine Erneuerung.

3 Prinzip des Lagerabzugs

Wenn Sie das optimistische Sperrprinzip in Kapitel 2 verstehen, ist das Prinzip des Lagerabzugs bereits klar. Wir gehen davon aus, dass nur noch 1 Artikel auf Lager ist, wenn zwei Threads gleichzeitig den Lagerabzug durchführen Mit der Zeit wird es passieren. Handelt es sich um eine überverkaufte Situation?

Zum Zeitpunkt t2 führen Sitzung1 und Sitzung2 gleichzeitig updatek aus, um den Bestand zu reduzieren. Da durch das Update eine exklusive Sperre hinzugefügt wird, kann nur eine der beiden erfolgreich sein: Sitzung1 ist erfolgreich und Sitzung2 blockiert das Warten auf die exklusive Sperre freigelassen werden.

Zum Zeitpunkt t3 schreibt Sitzung1 die Transaktion fest und gibt die exklusive Sperre frei. Zu diesem Zeitpunkt erhält Sitzung2 die Sperre für das aktuelle Lesen, aber zu diesem Zeitpunkt ist der Bestand von Produkt 1 0 geworden und der (wobei Bestand - 1 > ;= 0) Bedingung ist nicht mehr erfüllt. Führen Sie die Anweisung aus. Die zu aktualisierenden Daten können nicht abgefragt werden, daher werden keine Datensätze aktualisiert.

Das obige ist der detaillierte Inhalt vonWas ist das Prinzip des optimistischen Lock-Deduction-Inventars in MySQL?. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!