Méthodes pour implémenter le mécanisme de transaction et le verrouillage optimiste dans Redis

小云云
Libérer: 2023-03-17 22:14:01
original
2550 Les gens l'ont consulté

Mécanisme de transaction Redis, dans MySQL et d'autres bases de données, une transaction représente un ensemble d'actions, qui sont soit toutes exécutées, soit pas exécutées du tout. Cet article présente principalement le mécanisme de transaction et le verrouillage optimiste dans Redis. L'analyse du verrouillage optimiste de Redis via l'exécution de transactions a une certaine valeur de référence. J'espère que cela pourra aider tout le monde.

Le support actuel de Redis pour les choses est relativement simple. Redis peut uniquement garantir que les commandes d'une transaction initiée par un client peuvent être exécutées en continu sans insérer d'autres commandes client au milieu. Lorsqu'un client émet une commande multi dans un lien, le lien entrera dans un contexte de transaction. Les commandes suivantes de la connexion ne seront pas exécutées immédiatement, mais seront d'abord placées dans une file d'attente. Lorsque la commande exec sera exécutée, redis l'exécutera. séquentiellement. Toutes les commandes dans la file d’attente.

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"
Copier après la connexion

Faites attention aux problèmes de transaction Redis : généralement, si une transaction échoue dans la file d'attente des transactions, la transaction entière sera annulée, mais les autres commandes de transaction dans Redis ne seront pas annulées.

Verrouillage optimiste : Redis est principalement implémenté sur la base du mécanisme d'enregistrement de la version des données (version). Il s'agit d'ajouter un identifiant de version aux données. Dans une solution de version basée sur une table de base de données, cela est généralement réalisé en ajoutant un champ de version à la table de base de données. Lors de la lecture des données, lisez ce numéro de version ensemble et ajoutez 1 à ce numéro de version lors d'une mise à jour ultérieure. À ce stade, le numéro de version des données soumises est comparé au numéro de version actuel de l'enregistrement correspondant dans la table de la base de données. Si le numéro de version des données soumises est supérieur au numéro de version actuel de la base de données, il sera mis à jour. , sinon elles seront considérées comme des données expirées.

watch monitoring : La commande watch surveillera la clé donnée. Si la clé surveillée a changé depuis l'appel de watch pendant l'exécution, la transaction entière échouera. Vous pouvez également appeler watch plusieurs fois pour surveiller plusieurs clés, afin que le verrouillage optimiste soit ajouté à la clé de transaction spécifiée. Notez que la clé de surveillance est valable pour l’ensemble du lien, et il en va de même pour les transactions. Si le lien est rompu, la montre et la transaction sont automatiquement effacées. Bien entendu, les commandes exex, throw et unwatch effaceront automatiquement toute surveillance dans le lien.

Implémentation du verrouillage optimiste dans redis :

En supposant qu'il existe une clé d'âge, nous ouvrons deux sessions pour attribuer des valeurs à l'âge.

session1 :

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
Copier après la connexion

session2 :

127.0.0.1:6379> set age 20
OK
127.0.0.1:6379> get age
"20"
Copier après la connexion

Exploiter directement l'âge dans la session2

Regardez à nouveau la session1 :

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"
Copier après la connexion

Ici, nous constatons que la transaction ne peut pas être exécutée avec succès, car la version des données dans la session1 est déjà plus petite que la version des données dans la base de données. Il s'agit d'un verrouillage optimiste dans Redis.

Recommandations associées :

Une brève introduction au mécanisme de transaction dans MySQL

Compréhension approfondie du mécanisme de transaction dans MySQL_MySQL

Vente flash de pratique de verrouillage optimiste Redis

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!

Étiquettes associées:
source:php.cn
Déclaration de ce site Web
Le contenu de cet article est volontairement contribué par les internautes et les droits d'auteur appartiennent à l'auteur original. Ce site n'assume aucune responsabilité légale correspondante. Si vous trouvez un contenu suspecté de plagiat ou de contrefaçon, veuillez contacter admin@php.cn
Tutoriels populaires
Plus>
Derniers téléchargements
Plus>
effets Web
Code source du site Web
Matériel du site Web
Modèle frontal