Redis transacties (via MULTI/EXEC) groeperen meerdere commando's om atomair uit te voeren — allemaal samen zonder dat andere commando's zich ertussen mengen. In combinatie met WATCH voor optimistische vergrendeling, verwerken ze scenario's waarbij meerdere bewerkingen consistent moeten zijn. Redis-transacties verschillen op belangrijke manieren van SQL-transacties.
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 begint met het in de wachtrij plaatsen van commando's; EXEC voert ze allemaal atomair uit (geen bemoeienissen van andere clients). DISCARD annuleert een transactie in de wachtrij.
# 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 biedt optimistische vergrendeling: als een gecontroleerde sleutel door een ander client wordt gewijzigd voordat EXEC wordt uitgevoerd, wordt de transactie afgebroken — zodat u veilig check-then-set-bewerkingen kunt uitvoeren (opnieuw proberen bij conflict).
⚠️ 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).
Het begrijpen van Redis-transacties is waardevol voor het consistent uitvoeren van meerdere bewerkingen, dus het is nuttige kennis — en het begrijpen hoe zij verschillen van SQL-transacties is vooral belangrijk om onjuiste aannames te vermijden.
De kernfunctionaliteit — MULTI/EXEC groepering van commando's voor atomaire uitvoering (allemaal samen, zonder dat commando's van andere clients zich ertussen mengen) — behandelt scenario's waarbij meerdere bewerkingen als een consistente eenheid moeten plaatsvinden.
De WATCH-mechanisme biedt optimistische vergrendeling (check-and-set): de transactie afbreken als een gecontroleerde sleutel voor EXEC is gewijzigd, waardoor veilige check-then-modify-bewerkingen mogelijk zijn (zoals het decrementeren van een saldo op basis van de huidige waarde) met opnieuw proberen bij conflict — belangrijk voor correct concurrente bewerkingen.
Het meest kritieke punt is het begrijpen hoe Redis-transacties verschillen van SQL-transacties: Redis heeft geen terugdraaien — als een commando op EXEC-moment mislukt, worden de andere commando's nog steeds uitgevoerd (Redis maakt niet ongedaan), dus "atomariteit" hier betekent dat commando's samen worden uitgevoerd zonder bemoeienissen (isolatie), NIET alles-of-niets met foutterugdraaien.
Misverstand hierover (aannemend dat SQL-achtig terugdraaien bestaat) leidt tot onjuiste foutafhandeling.
Weten dat Lua-scripts vaak worden gebruikt voor complexe atomaire logica (een script wordt atomair als eenheid uitgevoerd) is waardevol.
Aangezien consistente multi-operatie-uitvoering en correcte gelijktijdigheid echte behoeften zijn, en aangezien Redis-transacties (MULTI/EXEC met WATCH voor optimistische vergrendeling) deze aanpakken maar met belangrijke verschillen van SQL (geen terugdraaien) die moeten worden begrepen, is het begrijpen van Redis-transacties — MULTI/EXEC, WATCH-gebaseerde optimistische vergrendeling, en vooral het onderscheid geen-terugdraaien van SQL — waardevol, praktisch relevant kennis voor het correct gebruiken van Redis in gelijktijdige scenario's, waar het begrijpen van de verschillen met bekende SQL-transacties net zo belangrijk is als het mechanisme zelf.