Toutes les opérations de la transaction sont indivisibles dans la base de données, soit toutes sont terminées, soit aucune n'est exécutée.
L'exécution d'une transaction convertit les données d'un état à un autre avant le début de la transaction et après la fin de la transaction, les contraintes d'intégrité de la base de données ne sont pas violées.
L'isolement des transactions nécessite que les objets de chaque transaction en lecture-écriture soient séparés des objets d'opération des autres transactions, c'est-à-dire que la transaction n'est pas visible par les autres transactions avant d'être soumise.
Après que la base de données exécute une transaction, les modifications des données doivent être conservées et enregistrées. Lorsque la base de données est redémarrée, la valeur des données doit être la valeur modifiée.
L'exécution des transactions Redis comprend trois étapes, comme suit :
Le client utilise la commande MULTI pour démarrer explicitement une transaction.
Le serveur reçoit les opérations spécifiques envoyées par le client (telles que l'ajout, la suppression et la modification de données) et les exécute dans la transaction. Ces opérations sont les commandes de lecture et d'écriture de données fournies par Redis lui-même. Bien que ces commandes soient envoyées au serveur par le client, l'instance Redis ne stocke que temporairement ces commandes dans une file d'attente de commandes et ne les exécute pas immédiatement.
Seulement lorsqu'une commande EXEC est reçue et exécutée, Redis validera la transaction et exécutera réellement toutes les commandes de la file d'attente des transactions.
MULTI : ouvrez une transaction
EXEC : soumettez la transaction et exécutez toutes les commandes d'opération dans la file d'attente des commandes.
DISCARTE : abandonnez une transaction et effacez la file d'attente des commandes, mais ne peut pas prendre en charge l'annulation de la transaction.
REGARDER : Détectez si la valeur d'une ou plusieurs clés change pendant l'exécution de la transaction. Si elle change, alors la transaction en cours abandonne l'exécution.
Scénario 1 : Une erreur est signalée lors de l'exécution de la transaction lorsqu'elle est ajoutée à la file d'attente, puis Redis abandonnera l'exécution de la transaction pour garantir l'atomicité de la transaction.
Scénario 2 : La commande ne signale pas d'erreur lorsqu'elle est entrée dans la file d'attente, mais une erreur est signalée lorsqu'elle est effectivement exécutée. L'atomicité de la transaction ne peut pas être garantie.
Exemple de description du premier cas
127.0.0.1:6379> multi OK 127.0.0.1:6379> set t1 v1 QUEUED 127.0.0.1:6379> set t2 v2 QUEUED 127.0.0.1:6379> setget t3 (error) ERR unknown command 'setget' 127.0.0.1:6379> set t4 v4 QUEUED 127.0.0.1:6379> exec (error) EXECABORT Transaction discarded because of previous errors. 127.0.0.1:6379> get t4 (nil)
Explication : Avant d'exécuter la commande exec, si une erreur de syntaxe se produit (une commande inexistante est utilisée), alors lorsque la commande est mise en file d'attente, Redis signalera une erreur et enregistrera le erreur et attendez que la commande Exec soit exécutée. Ensuite, Redi rejettera toutes les commandes soumises et l'exécution de la transaction échouera. Dans ce cas, la transaction de Reid peut prendre en charge l'atomicité.
Exemple du deuxième cas
127.0.0.1:6379> multi OK 127.0.0.1:6379> incr s2 QUEUED 127.0.0.1:6379> set a1 v1 QUEUED 127.0.0.1:6379> set a2 v2 QUEUED 127.0.0.1:6379> exec 1) (error) ERR value is not an integer or out of range 2) OK 3) OK 127.0.0.1:6379> get a2 "v2"
Explication : La valeur de s2 est v2. Lors de l'exécution de la commande incr, une erreur est signalée car incr ne peut ajouter que des valeurs de type entier. Cependant, dans ce cas, nous avons constaté que la transaction Redis ne l'était pas. Les commandes suivantes peuvent être exécutées avec succès, de sorte que l'atomicité de la transaction ne peut pas être garantie dans ce cas.
Dans le premier cas, la transaction elle-même sera abandonnée, la cohérence de la transaction peut donc être garantie.
Dans le deuxième cas, la commande erronée ne sera pas exécutée, mais la commande correcte pourra être exécutée normalement. , et la cohérence de la base de données ne sera pas modifiée.
Si la persistance Redis est définie sur RDB, l'instantané RDB généré ne sera pas exécuté lorsque la transaction est exécutée, donc les résultats de l'opération de commande de transaction ne seront pas enregistrés dans l'instantané RDB, lors de l'utilisation de l'instantané RDB pour la récupération, les données de la base de données sont également cohérentes.
Si la persistance de Reids est définie sur AOF et que l'instance échoue avant que l'opération de transaction ne soit enregistrée dans le journal AOF, alors les données de la base de données restaurées à l'aide du journal AOF sont cohérentes. Si seules certaines opérations sont enregistrées dans le journal AOF, nous pouvons utiliser redis-check-aof pour effacer les opérations terminées dans la transaction, et la base de données sera cohérente après la récupération.
Afin d'obtenir l'isolation des transactions Redis, vous devez utiliser la commande watch. Le principe de Watch est que lors de la surveillance des modifications d'une ou plusieurs clés avant l'exécution d'une transaction, lorsque la transaction appelle la commande EXEC pour s'exécuter, le mécanisme WATCH vérifiera d'abord si les clés surveillées ont été modifiées par d'autres clients. Si la valeur du listener est modifiée, l'exécution de la transaction est abandonnée pour éviter que l'isolement de la transaction ne soit détruit.
Exemple de description
Client 1 :
127.0.0.1:6379> get blance "100" 127.0.0.1:6379> watch blance OK 127.0.0.1:6379> multi OK 127.0.0.1:6379> decrby blance 10 QUEUED 127.0.0.1:6379> incrby blance 10 QUEUED 127.0.0.1:6379> exec (nil)
Client 2 :
127.0.0.1:6379> get blance "100" 127.0.0.1:6379> set blance 90 OK 127.0.0.1:6379> get blance "90"
Explication : Le client 1 utilise la montre pour détecter le solde. Après avoir démarré la transaction, le client 2 effectue l'opération de modification de la valeur du solde pour simuler d'autres clients. Lors de l'exécution de la transaction, les données surveillées par la montre ont été modifiées, puis la commande EXEC du client 1 a été exécutée. Il a été constaté que la transaction n'avait pas été exécutée avec succès.
Les transactions Redis ne peuvent pas prendre en charge la persistance. Si Redis utilise le mode RDB, après l'exécution d'une transaction, mais avant l'exécution du prochain instantané RDB, l'instance Redis plante. Dans ce cas, les données modifiées par la transaction ne peuvent pas être garanties. Redis adopte le mode AOF, une perte de données peut se produire, que la configuration de persistance soit non, toutes les secondes ou toujours. Par conséquent, quel que soit le mode de persistance adopté par Redis, la durabilité des transactions ne peut pas être prise en charge.
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!
Logiciel de base de données couramment utilisé
Que sont les bases de données en mémoire ?
Lequel a une vitesse de lecture plus rapide, mongodb ou redis ?
Comment utiliser Redis comme serveur de cache
Comment Redis résout la cohérence des données
Comment MySQL et Redis assurent-ils la cohérence des doubles écritures ?
Quelles données le cache Redis stocke-t-il généralement ?
Quels sont les 8 types de données de Redis
![[Web front-end] Démarrage rapide de Node.js](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
