Maison > base de données > Redis > le corps du texte

Introduction aux transactions Redis et aux commandes associées

Libérer: 2019-11-27 16:38:37
avant
2573 Les gens l'ont consulté

Introduction aux transactions Redis et aux commandes associées

1. Présentation :

Comme beaucoup d'autres bases de données, Redis fournit également un mécanisme de transaction en tant que base de données NoSQL. Dans Redis, les quatre commandes MULTI/EXEC/DISCARD/WATCH sont la pierre angulaire de notre implémentation de transactions. Je pense que ce concept n'est pas étranger aux développeurs ayant une expérience en développement de bases de données relationnelles. Néanmoins, nous énumérerons brièvement les caractéristiques d'implémentation des transactions dans Redis : (Recommandé : tutoriel vidéo redis)

1. ). Toutes les commandes de la transaction seront exécutées dans un ordre sériel. Pendant l'exécution de la transaction, Redis ne fournira plus de services pour les autres demandes des clients, garantissant ainsi que toutes les commandes de la transaction sont exécutées de manière atomique.

2). Par rapport aux transactions dans les bases de données relationnelles, si une commande ne s'exécute pas dans une transaction Redis, les commandes suivantes continueront à être exécutées.

3). Nous pouvons démarrer une transaction via la commande MULTI, que les personnes ayant de l'expérience dans le développement de bases de données relationnelles peuvent comprendre comme l'instruction "BEGIN TRANSACTION". Les commandes exécutées après cette instruction seront considérées comme des opérations au sein de la transaction. Enfin, nous pouvons valider/annuler toutes les opérations au sein de la transaction en exécutant la commande EXEC/DISCARD. Ces deux commandes Redis peuvent être considérées comme équivalentes à l'instruction COMMIT/ROLLBACK dans une base de données relationnelle.

4). Avant le démarrage de la transaction, s'il y a un échec de communication entre le client et le serveur et que le réseau est déconnecté, toutes les instructions ultérieures à exécuter ne seront pas exécutées par le serveur. Cependant, si l'événement d'interruption du réseau se produit après que le client a exécuté la commande EXEC, toutes les commandes de la transaction seront exécutées par le serveur.

5). Lors de l'utilisation du mode Append-Only, Redis écrira toutes les opérations d'écriture de la transaction sur le disque lors de cet appel en appelant la fonction système write. Cependant, si une panne du système se produit pendant le processus d'écriture, telle qu'un temps d'arrêt provoqué par une panne de courant, seule une partie des données peut être écrite sur le disque à ce moment-là, tandis qu'une autre partie des données est perdue.

Le serveur Redis effectuera une série de contrôles de cohérence nécessaires lors du redémarrage. Une fois qu'un problème similaire est détecté, il se fermera immédiatement et affichera une invite d'erreur correspondante. À l'heure actuelle, nous devons utiliser pleinement l'outil redis-check-aof fourni dans la boîte à outils Redis. Cet outil peut nous aider à localiser les erreurs d'incohérence des données et à restaurer certaines des données écrites. Après la réparation, nous pouvons redémarrer le serveur Redis.

2. Liste des commandes associées :

Prototype de commande Complexité temporelle Description de la commande Valeur de retour

M

U

L

T

I


est utilisé pour marquer le début d'une transaction. Toutes les commandes exécutées par la suite seront stockées dans la file d'attente des commandes. Ces commandes ne seront pas exécutées de manière atomique jusqu'à ce que EXEC soit exécuté. Renvoie toujours OK

E

X

E

C


Exécutez toutes les commandes de la file d'attente de commandes au sein d'une transaction, tout en restaurant l'état de la connexion actuelle à l'état normal, c'est-à-dire l'état non transactionnel. Si la commande WATCH est exécutée lors d'une transaction, la commande EXEC peut exécuter toutes les commandes de la file d'attente des transactions uniquement si les clés surveillées par WATCH n'ont pas été modifiées. Sinon, EXEC abandonnera toutes les commandes de la transaction en cours. Renvoyer atomiquement les résultats de chaque commande de la transaction. Si WATCH est utilisé dans une transaction, EXEC renverra une réponse NULL multi-bulk une fois la transaction abandonnée.

D

I

S

C

A

R

D


Rétablissez toutes les commandes de la file d'attente des transactions et restaurez en même temps l'état de la connexion actuelle à l'état normal, c'est-à-dire l'état de non-transaction. Si la commande WATCH est utilisée, cette commande UNWATCH toutes les clés. Renvoie toujours OK.

W

A

T

C

H

k

e

y

[clé ...]

O(1) est exécuté dans le Commande MULTI Auparavant, vous pouviez spécifier les clés à surveiller. Cependant, si les clés surveillées sont modifiées avant d'exécuter EXEC, EXEC abandonnera l'exécution de toutes les commandes de la file d'attente des transactions. Renvoie toujours OK.

U

N

W

A

T

C

H

O(1) Annuler les clés surveillées spécifiées dans la transaction en cours Si la commande EXEC ou DISCARD est exécutée, ce n'est pas nécessaire. pour l'exécuter manuellement, car après cela, toutes les clés surveillées dans la transaction seront automatiquement annulées. Renvoie toujours OK.

3. Exemples de commandes :

1. La transaction est exécutée normalement :
#Exécutez l'outil client Redis sous la ligne de commande Shell.

 /> redis-cli
Copier après la connexion

#Démarrer une nouvelle transaction sur la connexion en cours.

redis 127.0.0.1:6379> multi
OK
Copier après la connexion
Copier après la connexion
Copier après la connexion

#Exécutez la première commande de la transaction. À partir du résultat renvoyé de la commande, nous pouvons voir que la commande n'est pas exécutée immédiatement, mais est stockée dans la file d'attente des commandes de la transaction.

redis 127.0.0.1:6379> incr t1
QUEUED
Copier après la connexion

#Une nouvelle commande est exécutée. Comme le montre le résultat, la commande est également stockée dans la file d'attente des commandes de la transaction.

redis 127.0.0.1:6379> incr t2
QUEUED
Copier après la connexion

#Exécuter toutes les commandes de la file d'attente des commandes de transaction Comme le montrent les résultats, les résultats des commandes de la file d'attente sont renvoyés.

redis 127.0.0.1:6379> exec
1) (integer) 1
2) (integer) 1
Copier après la connexion

2. Il y a une commande qui a échoué dans la transaction :
#Démarrer une nouvelle transaction.

redis 127.0.0.1:6379> multi
OK
Copier après la connexion
Copier après la connexion
Copier après la connexion

#Définissez la valeur de la clé a sur 3 de type chaîne.

redis 127.0.0.1:6379> set a 3
QUEUED
Copier après la connexion

# Pop l'élément de la tête de la valeur associée à la clé a Puisque la valeur est un type chaîne et que la commande lpop ne peut être utilisée que pour le type List, lors de l'exécution de l'exécution. commande, la commande échouera.

redis 127.0.0.1:6379> lpop a
QUEUED
Copier après la connexion

# Définissez à nouveau la valeur de la clé a sur la chaîne 4.

redis 127.0.0.1:6379> set a 4
QUEUED
Copier après la connexion

#Obtenez la valeur de la clé a pour confirmer si la valeur est définie avec succès par la deuxième commande set de la transaction.

redis 127.0.0.1:6379> get a
QUEUED
Copier après la connexion

# Il ressort des résultats que la deuxième commande lpop de la transaction n'a pas pu s'exécuter, mais que les commandes set et get suivantes ont été exécutées avec succès. Il s'agit de la transaction et du type relationnel de Redis. . La différence la plus importante entre les transactions dans une base de données.
redis 127.0.0.1:6379> exec
1) OK
2) (erreur) ERR Opération sur une clé contenant le mauvais type de valeur
3) OK
4) "4"
3. Annulation de la transaction :
#Définissez une valeur pour la clé t2 avant l'exécution de la transaction.

redis 127.0.0.1:6379> set t2 tt
OK
Copier après la connexion

#Démarrer une transaction.

redis 127.0.0.1:6379> multi
OK
Copier après la connexion
Copier après la connexion
Copier après la connexion

# Définissez une nouvelle valeur pour cette clé dans la transaction.

redis 127.0.0.1:6379> set t2 ttnew
QUEUED
Copier après la connexion

#Abandonner la transaction.

redis 127.0.0.1:6379> discard
OK
Copier après la connexion

#Voir la valeur de la clé t2 D'après les résultats, nous pouvons voir que la valeur de cette clé est toujours la valeur avant le début de la transaction.

redis 127.0.0.1:6379> get t2
"tt"
Copier après la connexion

4. Commande WATCH et verrouillage optimiste basé sur CAS :

Dans les transactions Redis, la commande WATCH peut être utilisée pour fournir CAS( fonction check-and-set). Supposons que nous surveillons plusieurs clés via la commande WATCH avant l'exécution de la transaction. Si la valeur d'une clé change après WATCH, la transaction exécutée par la commande EXEC sera abandonnée et une réponse multi-bulk Null sera renvoyée pour informer l'appelant. de la transaction.

Par exemple, nous supposons encore une fois que la commande incr n'est pas fournie dans Redis pour compléter l'incrément atomique des valeurs clés. Si nous voulons implémenter cette fonction, nous ne pouvons écrire que le code correspondant nous-mêmes. Le pseudo code est le suivant :

      val = GET mykey
      val = val + 1
      SET mykey $val
Copier après la connexion

Le code ci-dessus ne peut garantir que le résultat de l'exécution est correct que dans le cas d'une seule connexion, car s'il y a plusieurs clients exécutant ce code en même temps , Il y aura alors un scénario d'erreur qui se produit souvent dans les programmes multithreads - une condition de concurrence critique.

Par exemple, les clients A et B lisent tous deux la valeur originale de mykey en même temps. Supposons que la valeur soit 10. Après cela, les deux clients ajoutent un à la valeur et la redéfinissent sur le serveur Redis. . Cela fera que le résultat de mykey sera 11, et non 12 comme nous le pensons. Afin de résoudre des problèmes similaires, nous avons besoin de l'aide de la commande WATCH, voir le code suivant :

      WATCH mykey
      val = GET mykey
      val = val + 1
      MULTI
      SET mykey $val
      EXEC
Copier après la connexion

La différence avec le code précédent est que le nouveau code surveille la valeur de ma clé via WATCH commande avant d'obtenir la clé, puis entourez la commande set dans une transaction, ce qui peut effectivement garantir qu'avant d'exécuter EXEC pour chaque connexion, si la valeur de mykey obtenue par la connexion actuelle est modifiée par d'autres clients connectés, alors la commande EXEC de la connexion actuelle sera exécutée en échec. De cette façon, l'appelant peut savoir si val a été réinitialisé avec succès après avoir jugé la valeur de retour.

Pour plus de connaissances sur Redis, veuillez faire attention à la colonne Tutoriel 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:cnblogs.com
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