As transações em Redis (via MULTI/EXEC) agrupam múltiplos comandos para executar atomicamente — todos juntos sem que outros comandos se intercalem. Combinadas com WATCH para travamento otimista, elas lidam com cenários que exigem múltiplas operações consistentes. As transações Redis diferem das transações SQL de maneiras 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 o enfileiramento de comandos; EXEC os executa todos atomicamente (sem intercalação de outros clientes). DISCARD cancela uma transação enfileirada.
# 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 fornece travamento otimista: se uma chave observada for modificada por outro cliente antes de EXEC, a transação é abortada — permitindo que você faça operações check-then-set de forma segura (tente novamente em caso de conflito).
⚠️ 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).
Compreender as transações Redis é valioso para executar múltiplas operações de forma consistente, portanto é um conhecimento útil — e entender como elas diferem das transações SQL é especialmente importante para evitar suposições incorretas.
A capacidade principal — agrupamento MULTI/EXEC de comandos para executar atomicamente (todos juntos, sem que comandos de outros clientes se intercalem) — resolve cenários onde múltiplas operações devem acontecer como uma unidade consistente.
O mecanismo WATCH fornece travamento otimista (check-and-set): aborta a transação se uma chave observada foi alterada antes de EXEC, permitindo operações seguras de check-then-modify (como decrementar um saldo com base em seu valor atual) com tentativa novamente em caso de conflito — importante para operações concorrentes corretas.
O ponto mais crítico é entender como as transações Redis diferem das transações SQL: Redis não possui rollback — se um comando falhar no momento de EXEC, os outros comandos ainda são executados (Redis não desfaz), portanto "atomicidade" aqui significa que os comandos são executados juntos sem intercalação (isolamento), NÃO tudo-ou-nada com rollback de erro.
Não entender isso (assumindo rollback semelhante ao SQL) leva a manipulação incorreta de erros.
Saber que scripts Lua frequentemente são usados em vez disso para lógica atômica complexa (um script é executado atomicamente como uma unidade) é valioso.
Como a execução consistente de múltiplas operações e a concorrência correta são necessidades reais, e como as transações Redis (MULTI/EXEC com WATCH para travamento otimista) as abordam mas com diferenças importantes do SQL (sem rollback) que devem ser compreendidas, compreender as transações Redis — MULTI/EXEC, travamento otimista baseado em WATCH, e especialmente a distinção sem-rollback do SQL — é um conhecimento valioso e praticamente relevante para usar Redis corretamente em cenários concorrentes, onde entender as diferenças das transações SQL familiares é tão importante quanto o mecanismo em si.
Uma biblioteca de perguntas de entrevista de TI com respostas detalhadas — de Júnior a Sênior.
Doar