> Как обеспечить атомарность операций при увеличении счетчика запросов в Redis (JavaScript)

Короткий ответ

Атомарность при увеличении счетчика в Redis обеспечивается использованием команды INCR (или INCRBY), которая выполняется как одна атомарная операция на стороне сервера. Это исключает race conditions при конкурентных запросах. Для более сложной логики (например, чтение-модификация-запись) применяются Lua-скрипты через EVAL или транзакции с MULTI/EXEC и оптимистичными блокировками через WATCH.

Подробное объяснение

Redis - однопоточный по обработке команд, поэтому любая отдельная команда (например, INCR) выполняется атомарно: никакой другой запрос не может вмешаться в её выполнение. Это делает INCR идеальным решением для простого счетчика.

Однако если требуется атомарность для последовательности операций (например, прочитать значение, проверить условие, изменить), одной команды недостаточно. В таких случаях используются:

• Lua-скрипты (EVAL/EVALSHA): скрипт выполняется целиком как одна атомарная операция, так как Redis блокирует выполнение других команд на время его работы.
• Транзакции (MULTI/EXEC): команды внутри транзакции выполняются последовательно без прерываний, но без гарантии изоляции от других клиентов (нет rollback). Для проверки условий перед транзакцией используется WATCH (оптимистичная блокировка).

Выбор зависит от сложности логики: для простого инкремента - INCR, для условного обновления - Lua-скрипт, для пакетного выполнения независимых команд - транзакция.

На практике

В Node.js с библиотекой ioredis или redis:

• Для счетчика используйте client.incr('counter') - это гарантирует атомарность.
• Если нужно увеличить счетчик только при определенном условии (например, не превысить лимит), пишите Lua-скрипт: он выполняется атомарно и позволяет избежать race condition между проверкой и обновлением.
• Избегайте паттерна "get-then-set" (прочитать, изменить в коде, записать) - он не атомарен и приведет к потерям инкрементов при конкурентном доступе.
• Для высоконагруженных систем учитывайте, что Lua-скрипты блокируют Redis, поэтому они должны быть быстрыми (не выполняйте внутри них тяжелые вычисления или вызовы других сервисов).

Пример кода

JAVASCRIPT
const Redis = require('ioredis');
const redis = new Redis();

// Простой атомарный инкремент
async function incrementCounter(key) {
  const newValue = await redis.incr(key);
  return newValue;
}

// Атомарный инкремент с проверкой лимита через Lua-скрипт
const incrementWithLimitScript = `
  local current = redis.call('GET', KEYS[1])
  if current and tonumber(current) >= tonumber(ARGV[1]) then
    return 0
  end
  return redis.call('INCR', KEYS[1])
`;

async function incrementWithLimit(key, limit) {
  const result = await redis.eval(incrementWithLimitScript, 1, key, limit);
  return result === 1; // true если инкремент выполнен
}

Как отвечать на собеседовании

Начните с ключевой идеи: INCR - атомарная команда, этого достаточно для простого счетчика. Затем уточните, что для составных операций нужны Lua-скрипты или транзакции с WATCH. Приведите пример из Node.js, упомяните, что ioredis поддерживает eval. Подчеркните, что Lua-скрипты предпочтительнее для логики с условиями, так как они атомарны и не требуют повторных попыток. Если спросят про производительность, скажите, что INCR - самый быстрый вариант, а Lua-скрипты чуть медленнее из-за передачи скрипта, но всё ещё эффективны.

Что проверяет интервьюер

• Понимание модели выполнения Redis (однопоточность, атомарность команд).
• Умение различать атомарность одной команды и атомарность последовательности операций.
• Знание инструментов для атомарных составных операций: Lua-скрипты, транзакции, WATCH.
• Практический опыт работы с Redis из Node.js (библиотеки, API).
• Осознание trade-off: простота INCR vs гибкость Lua-скриптов vs блокировки.

Типичные ошибки

• Предложение паттерна "get-then-set" (read, modify in code, write) как атомарного решения.
• Утверждение, что MULTI/EXEC гарантирует атомарность чтения и записи без WATCH.
• Игнорирование Lua-скриптов и попытка реализовать условный инкремент через комбинацию GET + SET с блокировками.
• Непонимание, что Lua-скрипты блокируют Redis, и написание в них медленного кода (например, вызовов к внешним API).
• Использование INCR для операций, где нужно проверять значение перед изменением (приводит к race condition).