Le transazioni Redis (tramite MULTI/EXEC) raggruppano più comandi per eseguirli atomicamente — tutti insieme senza che altri comandi si interfaccino. Combinate con WATCH per il locking ottimistico, gestiscono scenari che richiedono più operazioni coerenti. Le transazioni Redis differiscono dalle transazioni SQL in modi importanti.
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 inizia l'accodamento dei comandi; EXEC li esegue tutti atomicamente (nessun interfacciamento da altri client). DISCARD annulla una transazione accodata.
# 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 fornisce locking ottimistico: se una chiave monitorata viene modificata da un altro client prima di EXEC, la transazione si interrompe — permettendoti di fare operazioni check-then-set in sicurezza (ritenta in caso di conflitto).
⚠️ 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).
Comprendere le transazioni Redis è prezioso per eseguire più operazioni in modo coerente, quindi è una conoscenza utile — e capire come differiscono dalle transazioni SQL è particolarmente importante per evitare assunzioni scorrette.
La capacità principale — il raggruppamento MULTI/EXEC di comandi per eseguire atomicamente (tutti insieme, senza che i comandi di altri client si interfaccino) — affronta scenari in cui più operazioni devono accadere come un'unità coerente.
Il meccanismo WATCH fornisce locking ottimistico (check-and-set): interrompe la transazione se una chiave monitorata è cambiata prima di EXEC, abilitando operazioni check-then-modify sicure (come decrementare un saldo in base al suo valore attuale) con ritenta in caso di conflitto — importante per operazioni concorrenti corrette.
Il punto più critico è comprendere come le transazioni Redis differiscono dalle transazioni SQL: Redis non ha rollback — se un comando fallisce al momento di EXEC, gli altri comandi vengono comunque eseguiti (Redis non annulla), quindi "atomicità" qui significa che i comandi vengono eseguiti insieme senza interfacciamento (isolamento), NON tutto-o-niente con rollback di errori.
Non capire questo (assumendo rollback stile SQL) porta a gestione degli errori scorretta.
Sapere che gli script Lua sono spesso usati invece per logica atomica complessa (uno script viene eseguito atomicamente come unità) è prezioso.
Poiché l'esecuzione coerente di più operazioni e la concorrenza corretta sono esigenze reali, e poiché le transazioni Redis (MULTI/EXEC con WATCH per locking ottimistico) le affrontano ma con differenze importanti da SQL (nessun rollback) che devono essere comprese, comprendere le transazioni Redis — MULTI/EXEC, locking ottimistico basato su WATCH, e soprattutto la distinzione senza-rollback da SQL — è una conoscenza prezioso e praticamente rilevante per usare Redis correttamente in scenari concorrenti, dove capire le differenze dalle transazioni SQL familiari è importante quanto il meccanismo stesso.