Redis транзакции (через MULTI/EXEC) группируют несколько команд для атомарного выполнения — все вместе без чередования с другими командами. В сочетании с WATCH для оптимистичной блокировки они обрабатывают сценарии, требующие согласованности нескольких операций. Транзакции Redis отличаются от SQL-транзакций важными способами.
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 начинает очередь команд; EXEC запускает их все атомарно (без чередования от других клиентов). DISCARD отменяет очередную транзакцию.
# 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 предоставляет оптимистичную блокировку: если наблюдаемый ключ модифицирован другим клиентом до EXEC, транзакция прерывается — позволяя безопасно выполнять операции проверка-затем-установка (повторная попытка при конфликте).
⚠️ 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).
Понимание транзакций Redis ценно для выполнения нескольких операций согласованно, поэтому это полезное знание — и понимание того, как они отличаются от SQL-транзакций, особенно важно, чтобы избежать неправильных предположений.
Основная возможность — группировка команд MULTI/EXEC для атомарного выполнения (все вместе, без чередования команд других клиентов) — решает сценарии, где несколько операций должны происходить как согласованная единица.
Механизм WATCH обеспечивает оптимистичную блокировку (проверка-и-установка): прерывание транзакции, если наблюдаемый ключ изменился до EXEC, позволяет безопасно выполнять операции проверка-затем-модификация (например, уменьшение баланса на основе его текущего значения) с повторной попыткой при конфликте — важно для корректных параллельных операций.
Критически важный момент — понимание того, как транзакции Redis отличаются от SQL-транзакций: Redis не имеет откката — если команда не выполняется во время EXEC, остальные команды всё равно выполняются (Redis не отменяет), поэтому «атомарность» здесь означает, что команды выполняются вместе без чередования (изоляция), НЕ всё-или-ничего с откатом при ошибке.
Неправильное понимание этого (предположение SQL-подобного отката) ведёт к некорректной обработке ошибок.
Знание того, что Lua-скрипты часто используются вместо этого для сложной атомарной логики (скрипт выполняется атомарно как единица), ценно.
Поскольку согласованное выполнение нескольких операций и корректная параллелизм — реальные потребности, и поскольку транзакции Redis (MULTI/EXEC с WATCH для оптимистичной блокировки) их решают, но с важными отличиями от SQL (нет отката), которые необходимо понимать, понимание транзакций Redis — MULTI/EXEC, оптимистичная блокировка на основе WATCH и особенно отличие без отката от SQL — это ценное, практически релевантное знание для правильного использования Redis в параллельных сценариях, где понимание различий от привычных SQL-транзакций столь же важно, как сам механизм.