Redis transakce (přes MULTI/EXEC) seskupují více příkazů, které se provádí atomicky — všechny najednou bez vzájemného prolínání s příkazy od jiných klientů. V kombinaci s WATCH pro optimistické zamykání zvládají scénáře vyžadující více operací s konzistentními výsledky. Redis transakce se od SQL transakcí liší důležitými způsoby.
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 zahajuje řazení příkazů do fronty; EXEC je spustí všechny atomicky (bez vzájemného prolínání od jiných klientů). DISCARD zruší transakci ve frontě.
# 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 poskytuje optimistické zamykání: pokud je sledovaný klíč změněn jiným klientem před EXEC, transakce se přeruší — umožňuje bezpečně provádět operace ověření-pak-nastavení (opakování v případě konfliktu).
⚠️ 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).
Pochopení Redis transakcí je cenné pro provádění více operací konzistentně, takže je to užitečné znalosti — a pochopení, jak se liší od SQL transakcí, je zvlášť důležité, aby se zabránilo nesprávným předpokladům.
Jádrem schopnosti — seskupení příkazů v MULTI/EXEC pro atomické provádění (všechny najednou, bez prolínání příkazů od jiných klientů) — se řeší scénáře, kdy více operací musí proběhnout jako konzistentní jednotka.
Mechanismus WATCH poskytuje optimistické zamykání (ověření a nastavení): přerušuje transakci, pokud se sledovaný klíč změnil před EXEC, což umožňuje bezpečné operace ověření-pak-změna (například snížení zůstatku na základě jeho aktuální hodnoty) s opakováním při konfliktu — důležité pro správné souběžné operace.
Nejkritičtější bod je pochopení, jak se Redis transakce liší od SQL transakcí: Redis nemá vrácení změn — pokud příkaz selže v čase EXEC, zbylé příkazy se stále provádějí (Redis nevrací), takže "atomicita" zde znamená, že příkazy běží spolu bez prolínání (izolace), NENÍ to vše-nebo-nic s vrácením chyby.
Neporozumění tomu (předpoklad vrácení jako v SQL) vede k nesprávnému zpracování chyb.
Znalost toho, že se Lua skripty často používají místo toho pro složitou atomickou logiku (skript se provádí atomicky jako jednotka), je cenná.
Protože konzistentní víceoperační provádění a správné souběžnosti jsou skutečné potřeby, a protože Redis transakce (MULTI/EXEC s WATCH pro optimistické zamykání) je řeší, ale s důležitými rozdíly od SQL (žádné vrácení), které musí být pochopeny, pochopení Redis transakcí — MULTI/EXEC, optimistické zamykání založené na WATCH, a zejména rozdíl bez-vrácení od SQL — je cenná, prakticky relevantní znalost pro správné používání Redis v souběžných scénářích, kde pochopení rozdílů od známých SQL transakcí je stejně důležité jako samotný mechanismus.