Qu'est-ce que l'ACID de transaction ? Les transactions Redis peuvent-elles implémenter ACID ?

Les transactions Redis prennent-elles en charge ACID ? L'article suivant vous amènera à comprendre les transactions Redis, à présenter comment Redis implémente les transactions et à déterminer si les transactions Redis prennent en charge ACID. J'espère que cela vous sera utile !

Intervieweur Tencent : « Connaissez-vous les transactions de Redis ? Son mécanisme de transaction peut-il réaliser des propriétés ACID ? »

Cheng Xuyuan : « Je me gratte la tête, ceci... Je sais que le script Lua peut réaliser des transactions ... "

Intervieweur Tencent : "D'accord, retourne en arrière et attends la notification."

---

Frère Ma, j'ai reçu beaucoup d'offres, mais je ne m'attendais pas à perdre à la fin sur la question « Comment Redis implémente-t-il les transactions ? »

Analysons-le étape par étape :

• Qu'est-ce que la transaction ACID ?

• Comment Redis implémente-t-il les transactions ?

• Quelles propriétés les transactions Redis peuvent-elles atteindre ?

• Implémentation du script Lua.

Quel est l'ACIDE des affaires

Dans "Yunnan Worm Valley" de Ghost Blowing the Lamp, le capitaine Mo Jin a un dicton : "Ensemble nous vivons, divisés nous mourons afin de trouver la perle Muchen." , tous les trois ont divisé leur travail. Ce n'est qu'en étant clair et en travaillant ensemble pour avancer et reculer ensemble que nous pourrons réussir.

La transaction est une unité de contrôle de concurrence, composée d'une séquence d'opérations, soit toutes ces opérations sont exécutées, soit aucune d'entre elles n'est exécutée. [Recommandations associées : Tutoriel vidéo Redis]

"C'est une unité de travail indivisible."

Lorsqu'une transaction est exécutée, elle fournira des garanties d'attributs spéciaux :

• Atomicité : plusieurs opérations d'une transaction doivent être terminées, ou aucune d'entre elles ne doit être terminée (ps : Comment MySQL atteint-il l'atomicité ? Commentaires de bienvenue dans le zone de message);

• Cohérence (Cohérence) : Une fois l'exécution de la transaction terminée, les contraintes d'intégrité de la base de données ne sont pas détruites et l'ordre d'exécution de la transaction est le statut légal des données.

  Les contraintes d'intégrité de la base de données incluent, sans s'y limiter :

  • L'intégrité de l'entité (telle que la clé primaire de la ligne existe et est unique)
  • L'intégrité de la colonne (telle que le type, la taille et la longueur de la) ; le champ doit répondre aux exigences)
  • Clés étrangères Contraintes
  • Intégrité définie par l'utilisateur (par exemple, la somme des soldes des deux comptes doit rester inchangée avant et après le transfert).

• Isolement : les opérations au sein d'une transaction sont isolées des autres transactions et les transactions exécutées simultanément ne peuvent pas interférer les unes avec les autres.

  Il se concentre sur l'interaction entre différentes transactions. L'isolement strict correspond au sérialisable (Serialised) au niveau d'isolement.

• Durabilité : Une fois la transaction soumise, toutes les modifications seront enregistrées de manière permanente dans la base de données, et les données ne seront pas perdues même si le système plante et redémarre.

Frère Ma, après avoir compris les exigences spécifiques d'ACID, comment Redis implémente-t-il le mécanisme de transaction ?

Comment Redis implémente les transactions

MULTI, EXEC, DISCARD et WATCH sont la base sur laquelle Redis implémente les transactions.

Le processus d'exécution d'une transaction Redis comprend trois étapes :

• Ouvrir la transaction

• Mettre la commande en file d'attente

• Démarrer explicitement ; un transaction

Le client démarre explicitement une transaction via la commande , et les commandes suivantes seront mises en file d'attente et mises en cache et ne seront pas réellement exécutées.

Mise en file d'attente des commandes

MULTI

Le client envoie une série d'instructions à exécuter dans la transaction au serveur. Il est à noter que bien que les instructions soient envoyées au serveur, l'instance Redis ne stocke que temporairement cette série d'instructions dans une file d'attente de commandes et ne les exécutera pas immédiatement.

Exécuter la transaction ou la supprimer

Le client envoie une commande pour soumettre ou rejeter la transaction au serveur, permettant à Redis d'exécuter les instructions spécifiques envoyées à la deuxième étape ou d'effacer la commande de file d'attente et d'abandonner l'exécution . Redis peut planifier l'exécution des commandes de file d'attente simplement lors de l'appel de EXEC .

Vous pouvez également utiliser

DISCARD

pour supprimer les commandes enregistrées dans la file d'attente lors de la deuxième étape.

Cas de transaction Redis

Exécutez notre exemple de code via le site Web de débogage en ligne : try.redis.io

Exécution normale

Exécutez un processus de transaction via MULTI et EXEC : MULTI 和 EXEC 执行一个事务过程：

# 开启事务
> MULTI
OK
# 开始定义一些列指令
> SET “公众号:码哥字节” "粉丝 100 万"
QUEUED
> SET "order" "30"
QUEUED
> SET "文章数" 666
QUEUED
> GET "文章数"
QUEUED
# 实际执行事务
> EXEC
1) OK
2) OK
3) OK
4) "666"

我们看到每个读写指令执行后的返回结果都是 QUEUED，表示谢谢操作都被暂存到了命令队列，还没有实际执行。

当执行了 EXEC 命令，就可以看到具体每个指令的响应数据。

放弃事务

通过 MULTI 和 DISCARD丢弃队列命令：

# 初始化订单数
> SET "order:mobile" 100
OK
# 开启事务
> MULTI
OK
# 订单 - 1
> DECR "order:mobile"
QUEUED
# 丢弃丢列命令
> DISCARD
OK
# 数据没有被修改
> GET "order:mobile"
"100"

码哥，Redis 的事务能保证 ACID 特性么？

这个问题问得好，我们一起来分析下。

Redis 事务满足 ACID？

Redis 事务可以一次执行多个命令， 并且带有以下三个重要的保证：

• 批量指令在执行 EXEC 命令之前会放入队列暂存；

• 收到 EXEC 命令后进入事务执行，事务中任意命令执行失败，其余的命令依然被执行；

• 事务执行过程中，其他客户端提交的命令不会插入到当前命令执行的序列中。

原子性

码哥，如果事务执行过程中发生错误了，原子性能保证么？

在事务期间，可能遇到两种命令错误：

• 在执行 EXEC 命令前，发送的指令本身就错误。如下：
  • 参数数量错误；
  • 命令名称错误，使用了不存在的命令；
  • 内存不足（Redis 实例使用 maxmemory指令配置内存限制）。
• 在执行 EXEC 命令后，命令可能会失败。例如，命令和操作的数据类型不匹配（对 String 类型 的 value 执行了 List 列表操作）；
• 在执行事务的 EXEC 命令时。 Redis 实例发生了故障导致事务执行失败。

EXEC 执行前报错

在命令入队时，Redis 就会报错并且记录下这个错误。

此时，我们还能继续提交命令操作。

等到执行了 EXEC

#开启事务
> MULTI
OK
#发送事务中的第一个操作，但是Redis不支持该命令，返回报错信息
127.0.0.1:6379> PUT order 6
(error) ERR unknown command `PUT`, with args beginning with: `order`, `6`,
#发送事务中的第二个操作，这个操作是正确的命令，Redis把该命令入队
> DECR b:stock
QUEUED
#实际执行事务，但是之前命令有错误，所以Redis拒绝执行
> EXEC
(error) EXECABORT Transaction discarded because of previous errors.

Nous voyons que le résultat renvoyé après l'exécution de chaque commande de lecture et d'écriture est QUEUED, ce qui signifie que l'opération de remerciement a été temporairement stockée dans la file d'attente des commandes et n'a pas été réellement exécutée. Lorsque la commande EXEC est exécutée, vous pouvez voir les données de réponse spécifiques de chaque commande.

Abandonner la transaction

Commande de file d'attente de suppression via MULTI et DISCARD :

rrreeeFrère Ma, les transactions Redis peuvent-elles garantir les caractéristiques ACID ?

C’est une bonne question, analysons-la ensemble.

Les transactions Redis satisfont-elles à ACID ?

Les transactions Redis peuvent exécuter plusieurs commandes à la fois et sont accompagnées des trois garanties importantes suivantes :

Les instructions par lots sont exécutées pendant EXEC La commande sera mise dans la file d'attente pour un stockage temporaire avant :

Entrez l'exécution de la transaction après avoir reçu la commande EXEC. Si une commande de la transaction ne parvient pas à s'exécuter, les commandes restantes sont toujours exécutées

Pendant l'exécution. processus d'exécution de la transaction, d'autres clients soumettent La commande n'est pas insérée dans la séquence d'exécution de la commande en cours.

Atomicity

Brother Code, si une erreur survient lors de l'exécution de la transaction, les performances atomiques sont-elles garanties ?

• Lors de la transaction, deux types d'erreurs de commande peuvent être rencontrées :
• Avant d'exécuter la commande EXEC, la commande elle-même est erronée. Comme suit :

Le nombre de paramètres est erroné ;

Le nom de la commande est erroné et une commande inexistante est utilisée Mémoire insuffisante (l'instance Redis utilise la directive maxmemory pour configurer le limite de mémoire).

Après avoir exécuté la commande EXEC, la commande peut échouer. Par exemple, les types de données de la commande et de l'opération ne correspondent pas (une opération de liste List est effectuée sur une valeur de type String) ;

Lors de l'exécution de la commande EXEC d'une transaction ; Un échec s'est produit dans l'instance Redis, entraînant l'échec de l'exécution de la transaction.

EXEC signale une erreur avant l'exécution

Lorsque la commande est mise en file d'attente, Redis

signalera une erreur et enregistrera l'erreur

.

À l'heure actuelle, nous pouvons toujours continuer à soumettre des opérations de commande.

Après avoir exécuté la commande EXEC, Redis

refusera d'exécuter toutes les opérations de commande soumises et renverra un résultat d'échec de transaction🎜. 🎜🎜De cette façon, 🎜toutes les commandes de la transaction ne seront plus exécutées, garantissant ainsi l'atomicité. 🎜🎜🎜Ce qui suit est un exemple d'erreur se produisant lorsqu'une commande est mise en file d'attente, entraînant un échec de transaction : 🎜rrreee🎜🎜EXEC signale une erreur après l'exécution🎜🎜🎜Lorsqu'une opération de transaction est mise en file d'attente, les types de données de la commande et L'opération ne correspond pas, mais l'instance Redis ne détecte pas l'erreur. 🎜🎜Cependant, après avoir exécuté la commande EXEC, Redis signalera une erreur lorsqu'il exécutera réellement ces instructions. 🎜🎜🎜Frappez au tableau : bien que Redis signale les erreurs en cas d'instructions incorrectes, la transaction exécutera toujours la commande correcte. À ce stade, l'atomicité de la transaction ne peut pas être garantie ! 🎜🎜🎜🎜Frère Ma, pourquoi Redis ne prend-il pas en charge la restauration ? 🎜🎜🎜En fait, Redis ne fournit pas de mécanisme de restauration. Bien que Redis fournisse la commande DISCARD. 🎜🎜Cependant, cette commande ne peut être utilisée que pour abandonner activement l'exécution d'une transaction et effacer la file d'attente de commandes temporaire, et n'a aucun effet de restauration. 🎜🎜🎜Un échec s'est produit lors de l'exécution d'EXEC🎜🎜🎜Si Redis active le journal AOF, alors seule une partie des opérations de transaction sera enregistrée dans le journal AOF. 🎜🎜Nous devons utiliser l'outil redis-check-aof pour vérifier le fichier journal AOF. Cet outil peut supprimer les opérations de transaction inachevées du fichier AOF. 🎜🎜De cette façon, après avoir utilisé AOF pour restaurer l'instance, l'opération de transaction ne sera plus exécutée, garantissant ainsi l'atomicité. 🎜🎜🎜Résumé simple🎜 : 🎜🎜🎜 Une erreur sera signalée lorsque la commande est ajoutée à la file d'attente, et l'exécution de la transaction sera abandonnée pour garantir l'atomicité ; 🎜🎜 Aucune erreur ne sera signalée lorsque la commande est ajoutée à la file d'attente, mais une erreur sera signalée lors de l'exécution effective, et l'atomicité n'est pas garantie ; 🎜🎜Exécution de la commande EXEC En cas d'échec de l'instance, si le journal AOF est activé, l'atomicité peut être garantie. 🎜🎜🎜🎜🎜Cohérence🎜🎜🎜🎜La cohérence sera affectée par le timing des commandes incorrectes et des échecs d'instance. Selon le timing des deux dimensions de l'erreur de commande et de l'échec de l'instance, elle peut être analysée dans trois situations. 🎜🎜🎜EXEC Avant l'exécution, si une erreur est signalée 🎜🎜🎜, la transaction sera abandonnée, afin de garantir la cohérence. 🎜🎜🎜Une fois EXEC exécuté, une erreur sera signalée lors de l'exécution réelle. 🎜🎜🎜Les erreurs ne seront pas exécutées. Les instructions correctes peuvent être exécutées normalement et la cohérence peut être garantie. 🎜🎜🎜Lorsque EXEC est exécuté, l'échec de l'instance 🎜🎜🎜 sera redémarré après l'échec de l'instance. Ceci est lié à la méthode de récupération des données. Nous en discuterons selon que l'instance a activé RDB ou AOF. 🎜

Si nous n'activons pas RDB ou AOF, après l'échec et le redémarrage de l'instance, les données disparaîtront et la base de données sera cohérente.

Si nous utilisons l'instantané RDB, car l'instantané RDB ne sera pas exécuté lors de l'exécution de la transaction.

Ainsi, 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 seront également cohérentes.

Si nous utilisons le journal 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 seront 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.

Isolation

L'exécution de la transaction peut être divisée en deux étapes : la mise en file d'attente de la commande (avant l'exécution de la commande EXEC) et l'exécution réelle de la commande (après l'exécution de la commande EXEC).

Ainsi lors de l'exécution simultanée, nous analysons ces deux étapes dans deux situations :

• Les opérations simultanées sont exécutées avant la commande EXEC, et l'isolation doit passer par WATCH Mécanisme garantie ; EXEC 命令前执行，隔离性需要通过 WATCH 机制保证；

• 并发操作在 EXEC 命令之后，隔离性可以保证。

码哥，什么是 WATCH 机制？

我们重点来看第一种情况：一个事务的 EXEC 命令还没有执行时，事务的命令操作是暂存在命令队列中的。

此时，如果有其它的并发操作，同样的 key 被修改，需要看事务是否使用了 WATCH

Opérations simultanées après la commande EXEC, l'isolement peut être garanti.

Frère Ma, quel est le mécanisme WATCH ?

Concentrons-nous sur la première situation : lorsque la commande EXEC d'une transaction n'a pas été exécutée, l'opération de commande de la transaction est temporairement stockée dans la file d'attente des commandes.

À ce stade, s'il y a d'autres opérations simultanées et que la même clé est modifiée, vous devez vérifier si la transaction utilise le mécanisme WATCH.

La fonction du mécanisme WATCH est de surveiller les changements de valeur d'une ou plusieurs clés avant qu'une transaction ne soit exécutée. 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.

En cas de modification, l'exécution de la transaction sera abandonnée pour éviter que l'isolement de la transaction ne soit détruit.

Dans le même temps, le client peut réexécuter la transaction. À ce moment, s'il n'y a pas d'opération simultanée pour modifier les données de la transaction, la transaction peut être exécutée normalement et l'isolement est également garanti.

Pas de WATCH

S'il n'y a pas de mécanisme WATCH, les opérations simultanées liront et écriront les données avant l'exécution de la commande EXEC.

Lorsque EXEC est exécuté, les données à exploiter dans la transaction ont changé et Redis ne parvient pas à isoler les transactions.

Les opérations simultanées sont reçues et exécutées après EXEC Quant au deuxième cas, parce que Redis utilise un seul thread pour exécuter les commandes, et après l'exécution de la commande EXEC, Redis s'assurera que toutes les commandes de la commande file d'attente sont exécutés en premier. Exécutez ensuite les instructions suivantes.

Donc, dans ce cas, les opérations simultanées ne briseront pas l'isolement de la transaction.

Persistance

Si Redis n'utilise pas RDB ou AOF, alors les propriétés de persistance de la transaction ne sont définitivement pas garanties.

Si Redis utilise le mode RDB, alors après l'exécution d'une transaction mais avant l'exécution du prochain instantané RDB, si un crash d'instance se produit et que des données sont perdues, dans ce cas, les données modifiées par la transaction ne peuvent pas être garanties. Si Redis adopte le mode AOF, il y aura une perte de données à cause des trois options de configuration du mode AOF : non, chaque seconde et toujours.

Ainsi, les propriétés de durabilité des transactions ne sont toujours pas garanties.

• Quel que soit le mode de persistance adopté par Redis, les propriétés de durabilité des transactions ne sont pas garanties.
• Résumé

Redis a un certain degré d'atomicité, mais ne prend pas en charge la restauration.

Redis n'a pas la notion de cohérence dans ACID. (Ou peut-être que Redis l'a ignoré lors de la conception)

Redis est isolé. Redis ne garantit pas la durabilité.

Le mécanisme de transaction de Redis peut garantir la cohérence et l'isolement, mais il ne peut pas garantir la durabilité.

🎜🎜Cependant, comme Redis lui-même est une base de données en mémoire, la persistance n'est pas un attribut nécessaire. Nous nous préoccupons davantage des trois attributs que sont l'atomicité, la cohérence et l'isolement. 🎜🎜La situation de l'atomicité est plus compliquée. 🎜Lorsque la syntaxe de commande utilisée dans la transaction est incorrecte, l'atomicité n'est pas garantie🎜 Dans d'autres cas, la transaction peut être exécutée de manière atomique. 🎜🎜Pour plus de connaissances sur la programmation, veuillez visiter : 🎜Introduction à la programmation🎜 ! ! 🎜

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!