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

Qu'est-ce qu'une transaction Redis

hzc
Libérer: 2020-06-28 14:31:08
original
2687 Les gens l'ont consulté

La transaction Redis peut exécuter plusieurs commandes à la fois. Il s'agit essentiellement d'un ensemble de commandes. Toutes les commandes d'une transaction seront sérialisées puis exécutées en série dans l'ordre sans être insérées.

Qu'est-ce qu'une transaction Redis

1. Qu'est-ce qu'une transaction Redis ?

Vous pouvez exécuter plusieurs commandes à la fois, ce qui est essentiellement un ensemble de commandes. Toutes les commandes d'une transaction seront sérialisées puis exécutées en série dans l'ordre sans être insérées dans d'autres commandes

2. Que peuvent faire les transactions Redis ?

Dans une file d'attente, une série de commandes sont exécutées séquentiellement et exclusivement

3 Comment utiliser la commande redis ?

1. Commandes liées à la transaction :

(1) DISCARD : annulez la transaction et abandonnez l'exécution de toutes les commandes du bloc de transaction

(2) EXEC : exécuter les commandes dans le bloc de transaction

(3) MULTI : Marquer le début d'une transaction

(4) UNWATCH : Annuler la surveillance de toutes les clés par la commande WATCH

(5) Clé WATCH [clé...] : Surveiller une (ou plusieurs) clés Si cette (ou ces) clés sont modifiées par d'autres commandes avant d'exécuter la transaction, la transaction sera interrompue.

2. Problème de rapport d'erreur de transaction :

(1) Erreur de déclaration : une erreur sera signalée directement lors de l'ajout de la file d'attente. Si cette erreur se produit, l'intégralité de la transaction sera annulée

(2) Erreur logique : Par exemple, si vous donnez une chaîne + 1, une erreur sera signalée lors de l'exécution. Ce type d'erreur n'affectera pas les autres opérations de la transaction. Seul cet article signalera une erreur

3. Surveillance de la surveillance :

(1) Verrouillage optimiste :

Verrouillage optimiste (Optimiste Lock), c'est un verrou optimiste. Chaque fois que vous allez chercher les données, vous pensez que d'autres ne modifieront pas les données, donc il ne se verrouillera pas. Cependant, lors de la mise à jour, il jugera si d'autres ont mis à jour les données pendant cette opération. période. Vous pouvez utiliser des mécanismes tels que le « numéro de version » qui sont utilisés de manière optimiste dans les types d'applications à lecture multiple, ce qui peut améliorer le débit.

 Stratégie de verrouillage optimiste : la version soumise doit être supérieure à la version actuellement enregistrée avant de pouvoir être mise à jour

  (2) Le verrouillage pessimiste

Le verrouillage pessimiste (Verrouillage pessimiste) est un verrou très pessimiste, chaque fois que vous allez chercher des données, vous penserez que d'autres fonctionneront selon la modification, ce qui entraînera un écrasement et d'autres problèmes. Ainsi, chaque fois que vous obtenez les données, elles seront verrouillées, donc si quelqu'un d'autre souhaite obtenir les données, elles seront bloquées une fois la modification terminée, le verrou peut être déverrouillé et utilisé. Les bases de données relationnelles traditionnelles utilisent de nombreux mécanismes de verrouillage de ce type. , tels que les verrous de ligne, les verrous de table, les verrous de lecture et les verrous d'écriture, qui verrouillent tous la table avant d'effectuer des opérations.

  Le verrouillage pessimiste garantit la sécurité des données, mais dégradera les performances

Quatre et trois fonctionnalités

1. Opération d'isolation séparée :

Toutes les commandes de la transaction seront sérialisées et exécutées dans l'ordre. Lors de l'exécution de la transaction, elle ne sera pas interrompue par les demandes de commandes envoyées par d'autres clients.

2. Il n'y a pas de notion de niveau d'isolement :

Les commandes dans la file d'attente ne seront pas réellement exécutées avant d'être soumises, car aucune instruction ne sera réellement exécutée avant que la transaction ne soit soumise, donc il n'y a pas de problème : "les requêtes au sein d'une transaction doivent voir les mises à jour physiques, mais les requêtes en dehors de la transaction ne peuvent pas voir ce problème"

 3. L'atomicité n'est pas garantie :

  Si redis est dans la même transaction. Si une commande ne parvient pas à s'exécuter, les commandes suivantes seront toujours exécutées sans restauration.

(À moins qu'une erreur ne se produise lors de l'entrée dans la file d'attente, c'est-à-dire une exception au moment de la compilation similaire à Java et une exception au moment de l'exécution, qui provoquera une restauration lors de la compilation, mais ne sera pas annulée en raison d'exceptions lors de l'exécution. )

Tutoriel recommandé : "

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:php.cn
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