Las transacciones en Redis (mediante MULTI/EXEC) agrupan múltiples comandos para ejecutarse atómicamente — todos juntos sin que otros comandos se intercalen. Combinadas con WATCH para bloqueo optimista, manejan escenarios que requieren que múltiples operaciones sean consistentes. Las transacciones en Redis difieren de las transacciones SQL de formas importantes.
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 inicia el encolamiento de comandos; EXEC los ejecuta todos atómicamente (sin intercalación de otros clientes). DISCARD cancela una transacción encolada.
# 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 proporciona bloqueo optimista: si otra cliente modifica una clave observada antes de EXEC, la transacción se aborta — permitiéndote hacer de forma segura operaciones de check-then-set (reintentar en caso de conflicto).
⚠️ 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).
Comprender las transacciones en Redis es valioso para realizar múltiples operaciones de forma consistente, por lo que es un conocimiento útil — y entender cómo difieren de las transacciones SQL es especialmente importante para evitar suposiciones incorrectas.
La capacidad principal — agrupar comandos MULTI/EXEC para ejecutarse atómicamente (todos juntos, sin que los comandos de otros clientes se intercalen) — aborda escenarios donde múltiples operaciones deben ocurrir como una unidad consistente.
El mecanismo WATCH proporciona bloqueo optimista (check-and-set): abortando la transacción si una clave observada cambió antes de EXEC, habilitando operaciones seguras de check-then-modify (como decrementar un saldo basado en su valor actual) con reintento en conflicto — importante para operaciones concurrentes correctas.
El punto más crítico es entender cómo las transacciones en Redis difieren de las transacciones SQL: Redis no tiene rollback — si un comando falla en el momento de EXEC, los otros comandos aún se ejecutan (Redis no deshace), por lo que la "atomicidad" aquí significa que los comandos se ejecutan juntos sin intercalación (aislamiento), NO todo-o-nada con rollback de error.
Malinterpretar esto (asumiendo rollback como SQL) lleva a manejo de errores incorrecto.
Saber que los scripts Lua a menudo se usan en su lugar para lógica atómica compleja (un script se ejecuta atómicamente como una unidad) es valioso.
Ya que la ejecución consistente de múltiples operaciones y la concurrencia correcta son necesidades reales, y ya que las transacciones en Redis (MULTI/EXEC con WATCH para bloqueo optimista) las abordan pero con diferencias importantes de SQL (sin rollback) que deben ser entendidas, entender las transacciones en Redis — MULTI/EXEC, bloqueo optimista basado en WATCH, y especialmente la distinción de sin-rollback de SQL — es conocimiento valioso y prácticamente relevante para usar Redis correctamente en escenarios concurrentes, donde entender las diferencias respecto a las transacciones SQL familiares es tan importante como el mecanismo en sí.