Ist die verteilte Sperre von Redis eine optimistische Sperre?

Einfach ausgedrückt verwendet Redis optimistisches Sperren, das einfacher zu implementieren ist als pessimistisches Sperren und in einigen Szenarien eine bessere Leistung bietet. Als leichte und schnelle Caching-Engine ist Redis keine voll funktionsfähige relationale Datenbank. Die Verwendung pessimistischer Sperren ist weder notwendig noch erschwinglich.

Optimistic Lock ist, wie der Name schon sagt, sehr optimistisch. Jedes Mal, wenn Sie die Daten abrufen, denken Sie, dass andere sie nicht ändern werden, also Sie wird es nicht sperren, aber beim Update können Sie überprüfen, ob andere diese Daten während des Updates aktualisiert haben. Optimistisches Sperren eignet sich für Anwendungstypen mit mehreren Lesevorgängen, wodurch der Durchsatz verbessert werden kann.

Optimistische Sperrstrategie: Die übermittelte Version muss größer als die aktuelle Version des Datensatzes sein, bevor Aktualisierungen durchgeführt werden können (empfohlenes Lernen: Redis-Video-Tutorial)

Nur ​​Redis bietet nur sehr begrenzte Unterstützung für Transaktionen, eigentlich eher ein Versuch, das Problem zu umgehen.

Erstens führt Redis eine Reihe von Vorgängen in derselben Transaktion nicht sofort aus, sondern stellt sie in eine Warteschlange. Wenn EXEC ausgeführt wird, werden sie zusammen ausgeführt. Die Transaktionsausführung ist global exklusiv, das heißt, es wird jeweils nur eine Transaktion ausgeführt und kann nicht durch andere Transaktionen in der Mitte unterbrochen werden. Redis verwendet diese einfachste und leistungsschwächste Methode, um Rennbedingungen zu vermeiden.

Zweitens gilt: Wenn bei einer Redis-Transaktion ein oder mehrere Vorgänge fehlschlagen, sind andere Vorgänge trotzdem erfolgreich, was bedeutet, dass es überhaupt keinen Rollback-Mechanismus gibt.

Diese Methode führt zu vielen schwerwiegenden Problemen. Eines davon ist, dass es unmöglich ist, zuerst einen bestimmten Wert zu lesen und dann Operationen auszuführen, die von diesem Wert abhängen, da das Einfügen in eine Transaktion zum selben Zeitpunkt erfolgt Wenn die Ausführung im selben Moment erfolgt, führt die Nichtplatzierung in derselben Transaktion zu Race-Bedingungen. Die Lösung besteht darin, WATCH zu verwenden, das eine oder mehrere Variablen überwacht. Wenn der Wert der Variablen nach dem Aufruf von WATCH und vor dem Festschreiben der Transaktion geändert wird, schlägt die gesamte Transaktion fehl. Dies ähnelt CAS (Compare and Set) in Betriebssystemen. Ich weiß nicht, wie WATCH konkret implementiert wird, aber ich vermute, dass es die Versionsnummer der angegebenen Variablen überwacht.

Selbst mit WATCH sind Redis-Transaktionen stark eingeschränkt. Erstens wird beim Lesen von Daten keine Konsistenz erreicht, da WATCH bei Lesevorgängen nicht funktioniert. Zweitens wird kein Rollback unterstützt. Drittens ist die Leistung bei einer großen Anzahl gleichzeitiger Schreibvorgänge für dieselbe Variable sehr schlecht, da bei jeder Übermittlung einer Transaktion die von WATCH überwachten Variablen geändert wurden, was dazu führt, dass die Übermittlung der Transaktion mehrmals fehlschlägt . Redis ist jedoch ursprünglich eine Cache-Engine vom Typ KV. Sie muss Szenarien mit großen Lesemengen und kleinen Schreibmengen bewältigen, und es besteht keine Anforderung an Konsistenz.

Weitere technische Artikel zum Thema Redis finden Sie in der Spalte Einführung in das Redis-Datenbanknutzungs-Tutorial, um mehr zu erfahren!

Das obige ist der detaillierte Inhalt vonIst die verteilte Sperre von Redis eine optimistische Sperre?. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!