Ce qui est
peut exécuter plusieurs commandes à la fois, ce qui est essentiellement un ensemble de commandes. Toutes les commandes d'une transaction seront sérialisées. seront sérialisées et exécutées dans l'ordre sans être insérées par d'autres commandes Aucun blocage n'est autorisé.
Exécutez plusieurs commandes Redis à la fois.
Ce qu'il peut faire
Exécuter une série de commandes dans une file d'attente en même temps, séquentiellement et exclusivement.
Comment jouer
Une transaction redis est ouverte à l'aide de la commande MULTI Cette commande répondra toujours OK, (je ne sais pas. s'il peut réussir), À ce stade, l'utilisateur peut exécuter plusieurs commandes à la fois au lieu de les exécuter une par une. redis les met en file d'attente et toutes les commandes seront appelées par la commande EXEC
DISCARD abandonne l'opération par lots.
Recommandé (gratuit) : Tutoriel Redis
Commandes communes
命令 | 描述 |
---|---|
DISCARD | 取消事务,放弃执行事务块内的所有命令。 |
EXEC | 执行所有事务块内的命令。 |
MULTI | 标记一个事务块的开始。 |
UNWATCH | 取消 WATCH 命令对所有 key 的监视。 |
WATCH key [key …] | 监视一个(或多个) key ,如果在事务执行之前这个(或这些) key 被其他命令所改动,那么事务将被打断。 |
Cas
Exécution normale
Abandonner la transaction
Tous d'affilée
Une erreur, tous d'affilée, non exécutée
Le créancier ennemi
Concernant ce problème, comment comprenez-vous la prise en charge des transactions par Redis ?
Redis prend en charge partiellement les transactions Dans cette partie, les bonnes sont exécutées et les mauvaises. ne sont pas exécutés.
cas : surveillance de la montre
Verrouillage pessimiste/Verrouillage optimiste/CAS (Vérifier et régler)
Verrouillage pessimiste, comme son nom l'indique, il est très pessimiste. Chaque fois que vous allez récupérer les données, vous pensez que d'autres les modifieront, vous les verrouillerez donc à chaque fois que vous obtiendrez les données. d'autres veulent obtenir les données, ils les bloqueront jusqu'à ce qu'elles obtiennent le verrou. De nombreux mécanismes de verrouillage de ce type sont utilisés dans les bases de données relationnelles traditionnelles, tels que les verrous de ligne, les verrous de table, les verrous de lecture, les verrous d'écriture, etc., qui sont tous verrouillés avant les opérations.
Verrouillage de la table : verrouillez toute la table. Cependant, cette table peut contenir de nombreuses données. À ce stade, un processus doit apporter des modifications à grande échelle, ce qui entraînera la mise en file d'attente de plus en plus de threads.
Verrouillage de ligne : verrouillez chaque enregistrement
Verrouillage optimiste
Verrouillage optimiste (Optimistic Lock), comme son nom l'indique, est très optimiste Chaque fois que vous allez chercher les données, vous pensez que les autres le feront. ne le modifiez pas, il ne sera donc pas verrouillé, mais lors de la mise à jour, il sera jugé si d'autres ont mis à jour les données pendant cette période. Vous pouvez utiliser des mécanismes tels que les numéros de version. Le verrouillage optimiste convient aux types d'applications à lectures multiples, ce qui peut améliorer le débit.
Stratégie de verrouillage optimiste : la version soumise doit être supérieure à la version actuelle de l'enregistrement avant que la mise à jour puisse être effectuée.
Le verrouillage optimiste n'est pas aveuglément optimiste. Par exemple, Zhang San a changé son compte WeChat et Li. Si a changé son compte QQ en même temps. À ce moment-là, le numéro de version était tous 1, puis Zhang San a fini de changer l'identifiant WeChat et l'a soumis. À ce moment-là, le numéro de version est passé de 1 à 2. Li Si également. l'a soumis après avoir terminé la modification. À ce moment-là, il est passé de 1 à 3 et une exception a été signalée.
Utilisez généralement le verrouillage optimiste au travail
Initialisez le solde disponible et le solde impayé de la carte de crédit
Aucune falsification, Surveillez d'abord, puis activez multi pour vous assurer que les deux changements de montant se font dans la même transaction
Lors de la surveillance, il a été constaté qu'une autre transaction avait modifié les données partagées, provoquant la transaction l'exécution échoue
Avant de modifier les données, vous devez verrouiller la montre, sinon une erreur se produira. Si quelqu'un modifie mes données, je signalerai une exception.
Il y a une falsification
La clé est surveillée Si la clé est modifiée, l'exécution de la prochaine transaction sera invalide
unwatch
Annuler la surveillance de toutes les clés par la commande watch
Une fois l'exécution exécutée, le verrou de surveillance ajouté avant l'exécution sera annulé
Résumé
L'instruction de surveillance est similaire au verrouillage optimiste. Lorsqu'une transaction est soumise, si la valeur de la clé a été modifiée par un autre client, par exemple, une liste a été poussée/extraite par un autre client, l'intégralité de la transaction. la file d'attente ne sera pas exécutée
Plusieurs clés sont surveillées avant l'exécution de la transaction via la commande WATCH 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 Nullmulti-bulk sera renvoyée. pour informer l'appelant que l'exécution de la transaction a échoué
3 phases
• Ouvrir : démarrer une transaction avec MULTI
• Mettre en file d'attente : mettre plusieurs commandes en file d'attente dans la transaction. La réception de ces commandes ne sera pas exécutée immédiatement, mais placée dans la file d'attente des transactions en attente d'exécution
• Exécution : transaction déclenchée par la commande EXEC
3 fonctionnalités
Opération d'isolation individuelle : toutes les commandes d'une transaction sont sérialisées et exécutées séquentiellement. Lors de l'exécution de la transaction, celle-ci ne sera pas interrompue par les demandes de commandes envoyées par d'autres clients.
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 tant qu'elles ne seront pas soumises, car aucune instruction ne sera réellement exécutée avant que la transaction ne soit soumise, il n'y a donc pas de "requête dans la transaction pour voir la transaction" La mise à jour dans le redis ne peut pas être vue lorsqu'elle est interrogée en dehors de la transaction. Il s'agit d'un problème très gênant
L'atomicité n'est pas garantie : si une commande ne parvient pas à s'exécuter dans la même transaction redis, les commandes suivantes seront toujours exécutées sans une réponse. Roll
AI qui ne suit pas l'ACID traditionnel
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!