Comment implémenter les transactions Redis

Description de l'attribut ACID

Atomicité(Atomicité)

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.

Cohérence

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.

Isolement

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.

Durabilité

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.

Comment Redis implémente les transactions

Principe d'implémentation

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.

Commandes liées aux 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.

Comment la transaction Redis prend-elle en charge ACID

La transaction Redis prend-elle en charge l'atomicité ?

• 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.

La transaction Redis prend-elle en charge la cohérence ?

Scénario 1 : Une erreur est signalée lorsque la commande est ajoutée à la file d'attente

Dans le premier cas, la transaction elle-même sera abandonnée, la cohérence de la transaction peut donc être garantie.

Cas 2 : Aucune erreur n'est signalée lorsque la commande est ajoutée à la file d'attente, mais une erreur est signalée lors de son exécution effective.

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.

Scénario 3 : L'instance Redis de la commande d'exécution échoue

• 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.

La transaction Redis prend-elle en charge l'isolement ?

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 prennent-elles en charge la persistance ?

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!