Methoden zur Implementierung von Transaktionsmechanismen und optimistischem Sperren in Redis

Redis-Transaktionsmechanismus. In MySQL und anderen Datenbanken stellt eine Transaktion eine Reihe von Aktionen dar, die entweder alle ausgeführt werden oder überhaupt nicht. In diesem Artikel werden hauptsächlich der Transaktionsmechanismus und das optimistische Sperren in Redis vorgestellt. Die Analyse des optimistischen Sperrens durch die Transaktionsausführung hat einen gewissen Referenzwert. Freunde, die es benötigen, können davon erfahren.

Die aktuelle Unterstützung von Redis für Dinge ist relativ einfach. Redis kann nur garantieren, dass Befehle in einer von einem Client initiierten Transaktion kontinuierlich ausgeführt werden können, ohne dass dazwischen weitere Client-Befehle eingefügt werden. Wenn ein Client einen Multi-Befehl in einem Link ausgibt, tritt der Link in einen Transaktionskontext ein. Nachfolgende Befehle der Verbindung werden nicht sofort ausgeführt, sondern zuerst in eine Warteschlange gestellt. Wenn der Exec-Befehl ausgeführt wird, führt Redis ihn aus Nacheinander alle Befehle in der Warteschlange.

Multi 开启事务：
127.0.0.1:6379[1]> multi #开启事务
OK
127.0.0.1:6379[1]> set age 15 #数据操作命令
QUEUED
127.0.0.1:6379[1]> set age 20 #数据操作命令
QUEUED
127.0.0.1:6379[1]> exec #执行事务
1) OK
2) OK
127.0.0.1:6379[1]> get age
"20"
Discard：取消事务，该命令实际是清空事务队列中的命令并退出事务上下文，也就是事务回滚。
127.0.0.1:6379[1]> get age
"20"
127.0.0.1:6379[1]> multi 
OK
127.0.0.1:6379[1]> set age 25
QUEUED
127.0.0.1:6379[1]> set age 30
QUEUED
127.0.0.1:6379[1]> discard #清空事务队列
OK
127.0.0.1:6379[1]> get age
"20"

Achten Sie auf Redis-Transaktionsprobleme: Wenn eine Transaktion in der Transaktionswarteschlange fehlschlägt, wird normalerweise die gesamte Transaktion zurückgesetzt, andere Transaktionsbefehle in Redis werden jedoch nicht zurückgesetzt.

Optimistische Sperre: Redis wird hauptsächlich basierend auf dem Aufzeichnungsmechanismus der Datenversion (Version) implementiert. Das heißt, den Daten eine Versionskennung hinzuzufügen. In einer Versionslösung, die auf einer Datenbanktabelle basiert, wird dies normalerweise durch Hinzufügen eines Versionsfelds zur Datenbanktabelle erreicht. Lesen Sie beim Lesen von Daten diese Versionsnummer zusammen und addieren Sie bei einer späteren Aktualisierung 1 zu dieser Versionsnummer. Zu diesem Zeitpunkt wird die Versionsnummer der übermittelten Daten mit der aktuellen Versionsnummer des entsprechenden Datensatzes in der Datenbanktabelle verglichen. Wenn die Versionsnummer der übermittelten Daten größer als die aktuelle Versionsnummer der Datenbank ist, werden sie aktualisiert , andernfalls werden sie als abgelaufene Daten betrachtet.

watch-Überwachung: Der watch-Befehl überwacht den angegebenen Schlüssel. Wenn sich der überwachte Schlüssel seit dem Aufruf von watch während der Ausführung geändert hat, schlägt die gesamte Transaktion fehl. Sie können watch auch mehrmals aufrufen, um mehrere Schlüssel zu überwachen, sodass dem angegebenen Transaktionsschlüssel eine optimistische Sperre hinzugefügt wird. Beachten Sie, dass der Überwachungsschlüssel für den gesamten Link gültig ist und das Gleiche auch für Transaktionen gilt. Wenn die Verbindung unterbrochen wird, werden sowohl die Überwachung als auch die Transaktion automatisch gelöscht. Natürlich löschen die Befehle „exex“, „discard“ und „unwatch“ automatisch die gesamte Überwachung im Link.

Implementierung des optimistischen Sperrens in Redis:

Angenommen, es gibt einen Altersschlüssel, öffnen wir zwei Sitzungen, um dem Alter Werte zuzuweisen.

Sitzung1:

127.0.0.1:6379> get age
"10"
127.0.0.1:6379> watch age #打开对age键的监控（监控其他操作是否对age键有修改操作）
OK
127.0.0.1:6379> multi #开启事务上下文
OK

Sitzung2:

127.0.0.1:6379> set age 20
OK
127.0.0.1:6379> get age
"20"

Alter direkt in Sitzung2 bearbeiten

Sehen Sie sich Sitzung1 noch einmal an:

127.0.0.1:6379> set age 30 #在session2中操作age后，我们在session1中继续操作age
QUEUED
127.0.0.1:6379> exec #执行事务 返回nil 事务执行不成功。
(nil)
127.0.0.1:6379> get age
"20"

Hier stellen wir fest, dass die Transaktion nicht erfolgreich ausgeführt werden kann. Dies liegt daran, dass die Datenversion in Sitzung1 bereits kleiner ist als die Datenversion in der Datenbank. Dies ist eine optimistische Sperre in Redis.

Verwandte Empfehlungen:

Eine kurze Einführung in den Transaktionsmechanismus in MySQL

Detailliertes Verständnis des Transaktionsmechanismus in MySQL_MySQL

Redis Optimistic Lock Practice Flash Sale

Das obige ist der detaillierte Inhalt vonMethoden zur Implementierung von Transaktionsmechanismen und optimistischem Sperren in Redis. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!