Redis transaksjoner (via MULTI/EXEC) grupperer flere kommandoer for å kjøre atomært — alle sammen uten at andre kommandoer blandes inn. Kombinert med WATCH for optimistisk låsing, håndterer de scenarier som trenger flere operasjoner for å være konsistente. Redis-transaksjoner skiller seg fra SQL-transaksjoner på viktige måter.
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 begynner å køe kommandoer; EXEC kjører dem alle atomært (ingen blanding fra andre klienter). DISCARD avbryter en køet transaksjon.
# 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 gir optimistisk låsing: hvis en overvåket nøkkel blir endret av en annen klient før EXEC, avbrytes transaksjonen — slik at du trygt kan gjøre sjekk-så-sett-operasjoner (prøv igjen ved 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).
Å forstå Redis-transaksjoner er verdifullt for å utføre flere operasjoner konsistent, så det er nyttig kunnskap — og å forstå hvordan de skiller seg fra SQL-transaksjoner er spesielt viktig for å unngå feilaktige antakelser.
Kjernefunksjonen — MULTI/EXEC gruppering av kommandoer for atomær kjøring (alle sammen, uten at andre klienters kommandoer blandes inn) — adresserer scenarier der flere operasjoner må skje som en konsistent enhet.
Mekanismen WATCH gir optimistisk låsing (sjekk-og-sett): avbryter transaksjonen hvis en overvåket nøkkel endret seg før EXEC, noe som muliggjør trygge sjekk-så-endre-operasjoner (som å redusere en balanse basert på dens nåværende verdi) med gjentaking ved konflikt — viktig for korrekte samtidige operasjoner.
Det viktigste punktet er å forstå hvordan Redis-transaksjoner skiller seg fra SQL-transaksjoner: Redis har ingen tilbakekjøring — hvis en kommando mislykkes på EXEC-tid, kjører de andre kommandoene fortsatt (Redis angrer ikke), så "atomaritet" her betyr at kommandoer kjører sammen uten blanding (isolasjon), IKKE alt-eller-ingenting med feilvalideringer.
Misforståelse av dette (som antar SQL-lignende tilbakekjøring) fører til feil feilbehandling.
Å vite at Lua-skript ofte brukes i stedet for kompleks atomær logikk (et skript kjører atomært som en enhet) er verdifullt.
Siden konsistent multi-operasjons-kjøring og korrekt samtidighet er virkelige behov, og siden Redis-transaksjoner (MULTI/EXEC med WATCH for optimistisk låsing) adresserer dem men med viktige forskjeller fra SQL (ingen tilbakekjøring) som må forstås, er det verdifullt, praktisk relevant kunnskap å forstå Redis-transaksjoner — MULTI/EXEC, WATCH-basert optimistisk låsing, og spesielt no-rollback-distinksjonen fra SQL — for å bruke Redis riktig i samtidige scenarier, der å forstå forskjellene fra kjente SQL-transaksjoner er like viktig som mekanismen selv.