Guide de prévention des fosses Redis – Transactions

Introduction aux commandes associées :

(Partage de vidéos d'apprentissage : Tutoriel vidéo Redis)

Remarque :

------MULTI, EXEC, DISCARD sont des commandes courantes pour démarrer et contrôler explicitement des transactions, qui peuvent être comparées à BEGAIN, COMMIT, ROLLBACK dans les bases de données relationnelles (en fait, l'écart Très grand);

------L'utilisation de la commande WATCH est de résoudre le problème des lectures non répétables et des lectures fantômes causées par la concurrence des transactions (simplement comprises comme le verrouillage de la clé

Transaction Redis

MULTI, EXEC, DISCARD et WATCH sont la base de la transaction Redis. Utilisés pour démarrer et contrôler explicitement une transaction, ils permettent d'exécuter un ensemble de commandes en une seule étape. Et offre deux garanties importantes :

Toutes les commandes de la transaction seront sérialisées et exécutées dans l'ordre. Lors de l'exécution d'une transaction Redis, aucune demande émise par un autre client ne se produira. Cela garantit que la file d’attente de commandes est exécutée comme une seule opération atomique.

Les commandes dans la file d'attente sont soit toutes traitées, soit ignorées. La commande EXEC déclenche l'exécution de toutes les commandes de la transaction. Ainsi, lorsque le client perd la connexion au serveur dans le contexte de la transaction, si cela se produit avant l'appel de la commande MULTI, aucune commande n'est exécutée si la commande EXEC est appelée ; avant cela, toutes les commandes sont exécutées.

Dans le même temps, redis utilise AOF (append-only file) pour écrire les transactions sur le disque à l'aide d'une opération d'écriture supplémentaire. En cas de temps d'arrêt ou de panne de processus, vous pouvez utiliser l'outil redis-check-aof pour réparer le fichier en ajout uniquement afin que le service puisse démarrer normalement et reprendre certaines opérations.

Utilisation

Utilisez la commande MULTI pour démarrer explicitement la transaction Redis. Cette commande répond toujours par OK. À ce stade, l'utilisateur peut émettre plusieurs commandes, et Redis n'exécutera pas ces commandes, mais les mettra en file d'attente. Une fois EXEC appelé, toutes les commandes seront exécutées. L’appel de DISCARD peut effacer la file d’attente des commandes dans la transaction et quitter la transaction.

L'exemple suivant incrémente atomiquement les clés foo et bar.

>MULTI
OK
>INCR foo
QUEUED
>INCR bar
QUEUED
>EXEC
1）（整数）1
2）（整数）1

Comme le montre l'exécution de la commande ci-dessus, EXEC renvoie un tableau, où chaque élément est le résultat de retour d'une seule commande dans la transaction, et l'ordre est le même que l'ordre dans lequel la commande a été émis. Lorsqu'une connexion Redis est dans le contexte d'une requête MULTI, toutes les commandes recevront une réponse avec la chaîne QUEUED (envoyée comme réponse d'état du point de vue du protocole Redis) et mises en file d'attente dans la file d'attente des commandes. Ce n'est que lorsque EXEC est appelé que les commandes en file d'attente seront exécutées et le résultat réel sera renvoyé à ce moment-là.

Erreurs dans les transactions

Lors d'une transaction, deux types d'erreurs de commande peuvent être rencontrées :

Une erreur s'est produite avant l'appel de la commande EXEC (échec de la file d'attente COMMAND). Par exemple, la commande peut contenir des erreurs de syntaxe (mauvais nombre de paramètres, mauvais nom de commande...) ou il peut y avoir certaines conditions critiques, comme une mémoire insuffisante (si le serveur a des limites de mémoire en utilisant la directive maxmemory).

Le client détectera la première erreur avant d'appeler EXEC. En vérifiant la réponse d'état de la commande en file d'attente (***Remarque : cela fait référence à la réponse d'état en file d'attente, pas au résultat de l'exécution***), si la commande répond par QUEUED, elle a été correctement mise en file d'attente, sinon Redis renverra un erreur. Si une erreur se produit lors de la mise en file d'attente d'une commande, la plupart des clients abandonnent la transaction et effacent la file d'attente des commandes. Cependant :

Avant Redis 2.6.5, dans ce cas, après l'appel de la commande EXEC, le client exécutait un sous-ensemble de commandes (celles qui avaient été mises en file d'attente avec succès) et ignorait les erreurs précédentes. À partir de Redis 2.6.5, le serveur se souviendra des erreurs survenues lors de l'accumulation de commandes. Lorsque la commande EXEC est appelée, il refusera d'exécuter la transaction et renverra ces erreurs, tout en effaçant automatiquement la file d'attente des commandes. Un exemple est le suivant :

>MULTI
+OK
>INCR a b c
-ERR wrong number of arguments for 'incr' command

Cela est dû à une erreur de syntaxe dans la commande INCR, qui sera détectée avant d'appeler EXEC et de terminer la transaction (version 2.6.5+).

Une erreur s'est produite après l'appel de la commande EXEC. Par exemple, utiliser une valeur incorrecte pour effectuer une opération sur une clé (comme appeler une opération List sur une valeur String)

Les erreurs qui surviennent après l'exécution de la commande EXEC ne seront pas traitées spécialement : même si certaines commandes de la transaction ne parviennent pas à s'exécuter, d'autres commandes seront toujours exécutées normalement.

L'exemple est le suivant :

>MULTI
+OK
>SET a 3
+QUEUED
>LPOP a
+QUEUED
>EXEC
*2
+OK
-ERR Operation against a key holding the wrong kind of value

EXEC renvoie un tableau de chaînes contenant deux éléments, un élément est OK, l'autre est -ERR…. La question de savoir si les erreurs peuvent être correctement renvoyées aux utilisateurs dépend de l'implémentation de la bibliothèque client (telle que Spring-data-redis.redisTemplate). Il convient de noter que même si la commande échoue, toutes les autres commandes de la file d'attente seront traitées - Redis n'arrêtera pas le traitement de la commande.

Les transactions Redis ne prennent pas en charge le Rollback (souligné)

En fait, les commandes Redis peuvent échouer lors de l'exécution de la transaction, mais les commandes restantes continueront à être exécutées au lieu du Rollback (rollback de la transaction). Si vous avez utilisé des bases de données relationnelles, cette situation peut vous paraître étrange. Il existe cependant une bonne explication à cette situation :

Redis命令可能会执行失败，仅仅是由于错误的语法被调用（命令排队时检测不出来的错误），或者使用错误的数据类型操作某个Key： 这意味着，实际上失败的命令都是编程错误造成的，都是开发中能够被检测出来的，生产环境中不应该存在。（这番话，彻底甩锅，“都是你们自己编程错误，与我们无关”。）由于不必支持Rollback,Redis内部简洁并且更加高效。

“如果错误就是发生了呢？”这是一个反对Redis观点的争论。然而应该指出的是，通常情况下，回滚并不能挽救编程错误。鉴于没有人能够挽救程序员的错误，并且Redis命令失败所需的错误类型不太可能进入生产环境，所以我们选择了不支持错误回滚（Rollback）这种更简单快捷的方法。

清除命令队列

DISCARD被用来中止事务。事务中的所有命令将不会被执行,连接将恢复正常状态。

> SET foo 1
OK
> MULTI
OK
> INCR foo
QUEUED
> DISCARD
OK
> GET foo
"1"

相关推荐：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!