Redis transaktioner (via MULTI/EXEC) grupperar flera kommandon för att köra atomärt — allt tillsammans utan att andra kommandon blandas in. Tillsammans med WATCH för optimistisk låsning hanterar de scenarier som kräver att flera operationer är konsekventa. Redis-transaktioner skiljer sig från SQL-transaktioner på viktiga sätt.
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 börjar köa kommandon; EXEC kör dem alla atomärt (ingen blandning från andra klienter). DISCARD avbryter en köad transaktion.
# 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 tillhandahåller optimistisk låsning: om en bevakad nyckel ändras av en annan klient innan EXEC, avbryts transaktionen — vilket gör att du säkert kan genomföra check-then-set-operationer (försök igen vid konflikt).
⚠️ 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).
Att förstå Redis-transaktioner är värdefullt för att utföra flera operationer konsekvent, så det är användbar kunskap — och att förstå hur de skiljer sig från SQL-transaktioner är särskilt viktigt för att undvika felaktiga antaganden.
Huvudförmågan — MULTI/EXEC gruppering av kommandon för atomär körning (allt tillsammans, utan att andra klienters kommandon blandas in) — hanterar scenarier där flera operationer måste hända som en konsekvent enhet.
Mekanismen WATCH tillhandahåller optimistisk låsning (check-and-set): avbryts transaktionen om en bevakad nyckel ändrades innan EXEC, vilket möjliggör säkra check-then-modify-operationer (som att minska ett saldo baserat på dess aktuella värde) med försök igen vid konflikt — viktigt för korrekta parallella operationer.
Den mest kritiska punkten är att förstå hur Redis-transaktioner skiljer sig från SQL-transaktioner: Redis har ingen rollback — om ett kommando misslyckas vid EXEC-tid, kör de andra kommandona fortfarande (Redis gör ingen undo), så "atomicitet" här betyder att kommandon körs tillsammans utan blandning (isolering), INTE allt-eller-inget med felåterställning.
Fel förståelse av detta (antagande om SQL-liknande rollback) leder till felaktig felhantering.
Att veta att Lua-skript ofta används istället för komplex atomär logik (ett skript körs atomärt som en enhet) är värdefullt.
Since konsekvent multi-operation-körning och korrekt parallellism är verkliga behov, och eftersom Redis-transaktioner (MULTI/EXEC med WATCH för optimistisk låsning) hanterar dem men med viktiga skillnader från SQL (ingen rollback) som måste förstås, är det värdefullt, praktiskt relevant kunskap att förstå Redis-transaktioner — MULTI/EXEC, WATCH-baserad optimistisk låsning, och särskilt no-rollback-skillnaden från SQL — för att använda Redis korrekt i parallella scenarier, där förståelsen för skillnader från kända SQL-transaktioner är lika viktig som mekanismen själv.