Поддержка транзакций в Redis: MULTI, EXEC, WATCH

Redis — одна из самых популярных in-memory баз данных, используемых для кэширования, хранения сессий, реализации очередей и других задач, требующих высокой скорости. Однако помимо производительности, разработчики часто сталкиваются с необходимостью обеспечить целостность данных при выполнении нескольких операций. В отличие от традиционных СУБД, Redis не поддерживает полноценные ACID-транзакции в классическом понимании, но предоставляет механизм, позволяющий группировать команды и управлять их выполнением: MULTI, EXEC и WATCH. Эти команды формируют основу для реализации логических транзакций в Redis.

Как работают MULTI и EXEC: основы группировки команд

Когда в Redis необходимо выполнить несколько команд как единый блок, используется команда MULTI. Она начинает транзакцию, после чего все последующие команды не выполняются немедленно, а помещаются в очередь. Выполнение этих команд происходит только после вызова EXEC, который запускает весь набор команд атомарно.
Атомарность здесь означает, что все команды из очереди будут выполнены подряд без прерываний со стороны других клиентов. Это достигается за счёт того, что Redis — однопоточный сервер. Однако важно понимать: атомарность не гарантирует отсутствие ошибок или откат изменений при их возникновении.
Рассмотрим простой сценарий: перевод баланса между двумя пользователями.

WATCH user:100:balance user:200:balance
MULTI
DECRBY user:100:balance 50
INCRBY user:200:balance 50
EXEC

В этом примере мы сначала отслеживаем два ключа с помощью WATCH, затем начинаем транзакцию через MULTI, добавляем команды изменения балансов и завершаем выполнение через EXEC.
Если во время выполнения транзакции ни один из отслеживаемых ключей не был изменён другим клиентом, EXEC вернёт массив результатов каждой команды. Если же произошло изменение, EXEC вернёт (nil), сигнализируя о провале транзакции.

Жизненный цикл транзакции

• Начало: клиент отправляет MULTI, Redis переходит в режим сбора команд.
• Сбор: каждая последующая команда (кроме EXEC, DISCARD, WATCH) добавляется в очередь.
• Выполнение: при получении EXEC Redis атомарно выполняет все команды и возвращает массив результатов.
• Отмена: DISCARD очищает очередь и выходит из режима транзакции.

Важно, что после MULTI клиент должен обязательно вызвать либо EXEC, либо DISCARD. В противном случае соединение остаётся «подвешенным», что может привести к утечке ресурсов.

WATCH — контроль за состоянием ключей перед выполнением

Команда WATCH является ключевым элементом механизма оптимистичной блокировки в Redis. Она позволяет отслеживать один или несколько ключей на предмет изменений со стороны других клиентов. Если хотя бы один из отслеживаемых ключей был изменён до вызова EXEC, транзакция автоматически откатывается.
Это особенно полезно в условиях высокой нагрузки, когда несколько процессов могут одновременно пытаться изменить одни и те же данные. Например, при инкременте счётчика просмотров:

WATCH views:post:123
current = GET views:post:123
MULTI
SET views:post:123 [current + 1]
EXEC

Если другой клиент изменил views:post:123 между GET и EXEC, транзакция не выполнится, и нужно будет повторить попытку.

Как работает WATCH под капотом?

• При вызове WATCH key Redis регистрирует текущую версию ключа (по сути — метку времени или внутренний счётчик).
• При любой записи в этот ключ (SET, INCR, DEL и др.) Redis помечает соединение как «грязное».
• При вызове EXEC Redis проверяет, не было ли изменений в отслеживаемых ключах. Если были — возвращается (nil).

Особенности WATCH

• Не блокирует: другие клиенты могут свободно читать и изменять отслеживаемые ключи.
• Только на запись: изменение ключа командой записи (SET, DEL и т.п.) срабатывает как триггер, чтение — нет.
• Автоматический сброс: после EXEC или DISCARD все отслеживания снимаются.

Что происходит при сбое транзакции в Redis?

В отличие от реляционных баз данных, Redis не поддерживает механизм rollback. Если одна из команд внутри EXEC завершается с ошибкой (например, деление на ноль в Lua-скрипте), предыдущие команды уже выполнены и не будут отменены.
Рассмотрим пример:

MULTI
SET key1 "value"
INCR key1 -- Ошибка: нельзя инкрементировать строку
SET key2 "done"
EXEC

Результат: key1 остаётся строкой «value», key2 не будет установлен, потому что ошибка на уровне выполнения прервёт всю последовательность? Нет. На самом деле, Redis продолжит выполнять команды, но результат команды INCR будет Error, а SET key2 всё равно выполнится.
Такое поведение связано с тем, что Redis не анализирует семантику команд до выполнения. Он лишь собирает их в очередь. Поэтому ответственность за корректность лежит на клиенте.

Стратегии обработки сбоев

1. Повторная попытка (retry): если EXEC вернул (nil), повторите транзакцию с начала.
2. Логирование ошибок: фиксируйте случаи, когда команды возвращают ошибки выполнения.
3. Проверка состояния: перед началом транзакции убедитесь, что типы данных корректны.
4. Альтернатива — Lua-скрипты: они выполняются атомарно и позволяют контролировать ошибки.

Практические примеры использования транзакций

Рассмотрим реальные сценарии, где MULTI, EXEC и WATCH решают конкретные задачи.

Пример 1: Перевод средств между счетами

WATCH balance:user:alice, balance:user:bob
MULTI
DECRBY balance:user:alice 100
INCRBY balance:user:bob 100
EXEC

Если баланс Алисы меньше 100, команда DECRBY не вернёт ошибку, но значение станет отрицательным. Чтобы избежать этого, нужно проверять баланс до транзакции:

balance = GET balance:user:alice
if tonumber(balance) < 100 then
 return "Недостаточно средств"
end
-- Затем транзакция

Но между проверкой и MULTI баланс может измениться. Решение — использовать Lua:

EVAL "
 local bal = redis.call('GET', KEYS[1])
 if not bal or tonumber(bal) < tonumber(ARGV[1]) then
 return 0
 end
 redis.call('DECRBY', KEYS[1], ARGV[1])
 redis.call('INCRBY', KEYS[2], ARGV[1])
 return 1
" 2 balance:user:alice balance:user:bob 100

Пример 2: Распределённый счётчик с ограничением

Нужно увеличить счётчик, но не более N раз в минуту.

WATCH rate_limit:123
current = GET rate_limit:123
if current and tonumber(current) >= 100 then
 return "Лимит исчерпан"
end
MULTI
INCR rate_limit:123
EXPIRE rate_limit:123 60
EXEC

Если EXEC вернёт (nil), значит, другой процесс изменил счётчик — нужно повторить.

Пример 3: Атомарное создание и обновление связанных данных

Создаём заказ и обновляем статистику пользователя:

MULTI
HSET order:456 user_id 789 status new created_at "2026-04-16T10:00:00"
HINCRBY user:789 stats:orders 1
SADD user:789:orders 456
EXEC

Все три операции выполняются атомарно. Даже если Redis перезапустится после первой команды, данные могут быть потеряны — Redis не гарантирует durability без настроенной persistence.

Распространённые ошибки и как их избежать

Механизм транзакций в Redis прост, но содержит подводные камни.

Ошибка 1: Предположение, что Redis откатывает изменения при ошибках

Как уже говорилось, Redis не поддерживает rollback. Если первые команды успешны, а последняя падает — изменения сохранятся.
Решение: используйте Lua-скрипты для сложной логики или проверяйте состояние перед выполнением.

Ошибка 2: Избыточное использование WATCH

Отслеживание десятков ключей увеличивает вероятность конфликта и снижает пропускную способность.
Решение: минимизируйте число WATCH, используйте составные ключи или шардирование.

Ошибка 3: Бесконечные циклы повтора

При частых конфликтах retry-логика может зациклиться.
Решение: ограничьте число попыток (например, до 5) и добавьте экспоненциальную задержку.

for i = 1, max_retries do
 WATCH ...
 -- логика
 result = EXEC
 if result ~= nil then break end
 usleep(100 * (2^i)) -- экспоненциальная задержка
end

Ошибка 4: Использование MULTI без WATCH там, где это нужно

Если данные могут измениться между чтением и записью, без WATCH возможны race condition.
Решение: всегда используйте WATCH, если транзакция зависит от текущего значения ключа.

Экспертное мнение

Транзакции в Redis — это инструмент для атомарного выполнения группы команд, а не замена реляционной модели. Они эффективны, когда используются правильно, но требуют понимания ограничений.
Главный принцип: проектируйте логику приложения так, чтобы она была устойчива к частичным изменениям и конфликтам. Используйте транзакции для простых сценариев, а для сложной бизнес-логики переходите на Lua.
Также важно помнить, что Redis — это in-memory хранилище. Даже с AOF и RDB есть риск потери данных. Для финансовых систем или критичных операций лучше использовать реляционные базы с полной поддержкой ACID.
Если же нужна высокая скорость и согласованность на уровне операций — Redis с MULTI/EXEC/WATCH остаётся одним из лучших решений.

Вопросы и ответы

Заключение

Механизмы MULTI, EXEC и WATCH — это мощный, но ограниченный инструмент для управления целостностью данных в Redis. Они позволяют группировать команды, обеспечивать атомарность и контролировать конкурентный доступ, но не заменяют полноценные транзакции реляционных СУБД.

• Используйте MULTI/EXEC для атомарного выполнения команд, но помните: ошибки не откатывают предыдущие действия.
• WATCH — ваш инструмент против гонок данных, но он требует реализации retry-логики.
• Для сложной логики предпочтительны Lua-скрипты — они атомарны и гибки.
• Ограничивайте число попыток при повторе транзакций, чтобы избежать бесконечных циклов.
• Учитывайте особенности Redis Cluster: все ключи в транзакции должны быть в одном слоте.