Как Redis обрабатывает команды и сохраняет атомарность
Как Redis обрабатывает запросы внутри и за счет чего отдельные команды выглядят атомарными и согласованными для клиента?
Ответить самому
Сначала сформулируйте ответ как на собеседовании, затем откройте разбор и оцените себя.
Короткий ответ
Классический Redis выполняет команды для shard через single-threaded event loop: одна команда меняет in-memory состояние до конца, потом берется следующая. Но multi-command workflow все равно требует Lua, MULTI/EXEC, WATCH или idempotency.
Полный разбор
Redis хранит данные в памяти и обрабатывает команды последовательно в event loop. Поэтому отдельная команда вроде SET, HSET или INCR не interleave-ится с другой mutating командой и выглядит атомарной для клиента. Это объясняет, почему простые операции не создают race внутри одного shard.
Но из этого не следует, что любой бизнес-процесс автоматически консистентен. Если клиент делает read-modify-write несколькими командами, между ними может вмешаться другой клиент. Для таких случаев нужны atomic commands, MULTI/EXEC, Lua scripts, optimistic locking через WATCH или application-level idempotency.
В распределенном Redis дополнительно появляются replication lag, failover и cluster sharding. Single-threaded execution объясняет локальную атомарность команды, но не решает все вопросы consistency между репликами и shard-ами.
Теория
Атомарность одной Redis-команды отличается от консистентности многошаговой операции.
Типичные ошибки
- Говорить, что в Redis вообще не бывает race conditions.
- Забывать про read-modify-write из нескольких команд.
- Игнорировать replication и cluster semantics.
Как отвечать на собеседовании
- Приведите INCR как пример atomic command.
- Для нескольких шагов сразу назовите Lua или transactions.