Commandes liées aux transactions Redis :
Transaction ouverte : plusieurs
Fermer la transaction : rejeter
Valider la transaction : exec
Exécution normale des transactions :
127.0.0.1:6379> multi
OK
127.0.0.1:6379> définir le nom zhangsan
QUEUED
127.0.0.1:6379> définir l'âge 20
QUEUED
127.0.0.1:6379> définir haut 172
QUEUED
127.0.0.1:6379> exec
1) OK
2) D'accord
3) D'accord
127.0.0.1:6379>
Abandon d'activité
6379 > multi
OK _ _ _ _ _ _ _ 6379> obtenir le nom (néant) 127.0.0.1:6379>
Exception de compilation, erreur de code, erreur de commande
6379 > multi
OK _ _ _ _ _命令(error) ERR mauvais nombre d'arguments pour la commande 'getset' 127.0.0.1:6379> set wight 45 QUEUED 127.0.0.1:6379> exec (error) EXECABORT Transaction rejetée en raison d'erreurs précédentes. 127.0.0.1:6379> obtenir le nom (néant) 127.0.0.1:6379>
Exception d'exécution, à l'exception des erreurs de syntaxe qui ne seront pas exécutées et une exception est levée, d'autres commandes correctes peuvent être exécutées normalement
6379 > multi
OK _ _ _ _ _ _ _ 6379> exec 1) OK 2) OK 3) "23" 4) (erreur) La valeur ERR n'est pas un nombre entier ou hors plage 127.0.0.1:6379> get age "23" 127.0.0.1:6379>
Résumer:
De ce qui précède, on peut conclure que Redis prend en charge une seule transaction de commande, mais la transaction ne peut pas garantir l'atomicité (exécuter plusieurs commandes après avoir ouvert la transaction) !
Implémentation de Redis Optimistic Lock
Montre de test multi-thread
Thread un (ouvrir une fenêtre de ligne de commande):
127.0.0.1:6379> touches *
(liste vide ou ensemble)
127.0.0.1:6379> définir l'argent 100
OK
127.0.0.1:6379> définir le coût 0
OK
127.0.0.1:6379> regarder l'argent
OK
127.0.0.1:6379> multi
OK
127.0.0.1:6379> incrby money 20
QUEUED
127.0.0.1:6379> decrby cost 10
QUEUED
127.0.0.1:6379> exec ###Exécute la commande exec après l'exécution du thread 2
(nil)
127.0.0.1:6379>
Thread 2 (ouvrir une autre fenêtre de ligne de commande) Cette transaction est exécutée avant la validation de la transaction du thread 1
Il est constaté que lorsque le thread 2 modifie la valeur de la clé en tant qu'argent, puis que le thread 1 exécute la commande exec, le moniteur constate que la valeur de l'argent a changé, de sorte que l'exécution de la transaction échoue.
Verrouillage optimiste et verrouillage pessimiste
Verrou pessimiste : il y aura des problèmes à tout moment, il a donc été surveillé et aucun thread n'est autorisé à s'exécuter tant que l'étape en cours n'est pas terminée, ce qui est une perte de performances ! généralement pas utilisé
Verrou optimiste : jugez lors de la mise à jour des données et jugez si les données surveillées ont changé pendant cette période. S'il n'y a pas de changement, elles seront exécutées normalement, sinon l'exécution sera erronée.
Résumer:
Une seule commande est atomique dans redis, mais les transactions ne sont pas atomiques.
Redis peut prendre en charge le verrouillage optimiste