A Redis tranzakciók (a MULTI/EXEC paranccsokon keresztül) több parancsot csoportosítanak, hogy atomiálisan hajtódjanak végre — az egész csoport egyszerre, más parancsok közbevetése nélkül. A WATCH paranccsal kombinálva, amely optimista zárolást biztosít, olyan forgatókönyveket kezelnek, amelyek több konzisztens művelet szükségesek. A Redis tranzakciók számos ponton eltérnek az SQL tranzakcióktól.
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
A MULTI elindítja a parancsok sorbaállítását; az EXEC mindegyiket atomiálisan futtatja (más kliensek parancsai nem tudnak közbevetődni). A DISCARD megszakít egy sorbaállított tranzakciót.
# 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)
A WATCH optimista zárolást biztosít: ha az EXEC előtt egy másik kliens módosít egy figyelt kulcsot, a tranzakció megszakad — lehetővé téve az Ön számára a biztonságos ellenőrzés-majd-beállítás műveletek elvégzését (újrapróbálás ütközés esetén).
⚠️ 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).
A Redis tranzakciók megértése értékes a több művelet konzisztens végrehajtásához, így ez hasznos ismeret — és annak megértése, hogy hogyan térnek el az SQL tranzakcióktól, különösen fontos a helytelen feltételezések elkerüléséhez.
Az alapvető képesség — a MULTI/EXEC parancsok csoportosítása az atomi végrehajtáshoz (az egész csoport egyszerre, más kliens parancsai közbevetése nélkül) — olyan forgatókönyveket kezel, ahol több műveletnek konzisztens egységként kell megtörténnie.
A WATCH mechanizmus optimista zárolást biztosít (ellenőrzés-és-beállítás): a tranzakció azonnal véget ér, ha egy figyelt kulcs az EXEC előtt megváltozott, lehetővé téve az ellenőrzés-majd-módosítás műveletek biztonságos végzését (például egy egyenleg aktuális értéke alapján történő csökkentése) újrapróbálással ütközés esetén — kritikus a helyes párhuzamos műveletek elvégzéséhez.
A legszempontosabb pont annak megértése, hogy a Redis tranzakciók hogyan térnek el az SQL tranzakcióktól: a Redisnek nincs visszaállítás — ha egy parancs az EXEC időpontban meghiúsul, a többi parancs még mindig végrehajtódik (a Redis nem von vissza), így az "atomicitás" itt azt jelenti, hogy a parancsok egyszerre futnak közbevetés nélkül (izoláció), NEM pedig mindent-vagy-semmit hibás visszaállítás.
Ennek a félreértése (SQL-szerű visszaállítás feltételezése) helytelen hibakezeléshez vezet.
Annak tudatában, hogy Lua szkriptek gyakran használatosak helyette összetett atomi logikához (a szkript atomiálisan hajtódik végre egy egységként), értékes ismeret.
Mivel a konzisztens multi-operációs végrehajtás és a helyes párhuzamosság valódi szükségletek, valamint a Redis tranzakciók (MULTI/EXEC a WATCH-alapú optimista zárolással) kezelik ezeket, de fontos eltérésekkel az SQL-től (nincs visszaállítás), amelyeket meg kell érteni, a Redis tranzakciók megértése — MULTI/EXEC, WATCH-alapú optimista zárolás, és különösen a visszaállítás nélküli megkülönböztetés az SQL-től — értékes, gyakorlatban releváns ismeret a Redis helyes használatához párhuzamos forgatókönyvekben, ahol az eltérések ismerete az ismerős SQL tranzakcióktól ugyanolyan fontos, mint magának a mechanizmusnak a megértése.