Les transactions Redis (via MULTI/EXEC) regroupent plusieurs commandes pour les exécuter atomiquement — toutes ensemble sans que d'autres commandes s'intercalent. Combinées avec WATCH pour un verrouillage optimiste, elles gèrent les scénarios nécessitant que plusieurs opérations soient cohérentes. Les transactions Redis diffèrent des transactions SQL de manière importante.
MULTI # start a transaction (begin queuing commands)
SET account:1 100 # QUEUED (not executed yet)
SET account:2 200 # QUEUED
INCR counter # QUEUED
EXEC # execute ALL queued commands atomically (as one unit)
# → all commands run together, with NO other client's commands in between
MULTI commence à mettre les commandes en file d'attente ; EXEC les exécute toutes atomiquement (pas d'intercalage d'autres clients). DISCARD annule une transaction en file d'attente.
# WATCH a key; if it CHANGES before EXEC, the transaction ABORTS (returns nil)
WATCH balance
val = GET balance # read the current value
MULTI
SET balance (val - 100) # modify based on what we read
EXEC # → if "balance" changed since WATCH, EXEC fails (returns nil)
# → retry the whole thing if it failed (optimistic concurrency control)
WATCH fournit un verrouillage optimiste : si une clé surveillée est modifiée par un autre client avant EXEC, la transaction s'interrompt — vous permettant de faire en toute sécurité des opérations vérifier-puis-modifier (réessayer en cas de conflit).
⚠️ Redis transactions are NOT like SQL transactions:
✗ NO ROLLBACK — if a command fails at EXEC time, OTHER commands still execute
(errors don't roll back the transaction; Redis doesn't undo). Only syntax errors
before EXEC abort the whole thing.
✓ Atomicity = commands run together without interleaving (isolation), NOT all-or-nothing
with rollback on error.
→ Often Lua SCRIPTS are used instead for complex atomic logic (a script runs atomically).
Comprendre les transactions Redis est utile pour effectuer plusieurs opérations de manière cohérente, ce qui en fait une connaissance précieuse — et comprendre comment elles diffèrent des transactions SQL est particulièrement important pour éviter des hypothèses incorrectes.
La capacité essentielle — le regroupement MULTI/EXEC des commandes pour les exécuter atomiquement (toutes ensemble, sans que les commandes d'aucun autre client s'intercalent) — répond aux scénarios où plusieurs opérations doivent se produire comme une unité cohérente.
Le mécanisme WATCH fournit un verrouillage optimiste (vérification-et-modification) : interrompant la transaction si une clé surveillée a changé avant EXEC, permettant des opérations vérifier-puis-modifier sécurisées (comme décrémenter un solde en fonction de sa valeur actuelle) avec réessai en cas de conflit — important pour des opérations concurrentes correctes.
Le point critique est de comprendre comment les transactions Redis diffèrent des transactions SQL : Redis n'a pas de rollback — si une commande échoue au moment de EXEC, les autres commandes s'exécutent quand même (Redis ne défait rien), donc « l'atomicité » ici signifie que les commandes s'exécutent ensemble sans intercalage (isolation), PAS tout-ou-rien avec rollback d'erreur.
Ne pas comprendre cela (en supposant un rollback de type SQL) conduit à une gestion incorrecte des erreurs.
Savoir que les scripts Lua sont souvent utilisés à la place pour la logique atomique complexe (un script s'exécute atomiquement comme une unité) est utile.
Puisque l'exécution cohérente de plusieurs opérations et la concurrence correcte sont des besoins réels, et puisque les transactions Redis (MULTI/EXEC avec WATCH pour le verrouillage optimiste) y répondent mais avec des différences importantes par rapport à SQL (pas de rollback) qui doivent être comprises, comprendre les transactions Redis — MULTI/EXEC, le verrouillage optimiste basé sur WATCH, et en particulier la distinction sans-rollback par rapport à SQL — est une connaissance précieuse et pertinente en pratique pour utiliser Redis correctement dans des scénarios concurrents, où comprendre les différences par rapport aux transactions SQL familières est aussi important que le mécanisme lui-même.