Redis: распределение, отказоустойчивость и масштабирование
Предпосылки: репликация и шардинг (failover, кворум, shard key), Event loop, сеть (клиент/сервер), базовое понимание ключей и команд.
Redis удобно запускать как один процесс на одном сервере: все операции происходят локально, а данные лежат в RAM. В production обычно всплывают две практические боли:
- Отказ узла = отказ Redis. Перезапуск, падение процесса, проблема с сетью или диском — и сервисы, завязанные на Redis, начинают деградировать или падать вместе с ним.
- Один сервер перестаёт справляться. Либо по чтениям/соединениям, либо по объёму данных и скорости записи.
В Redis эти проблемы закрываются тремя связанными механизмами: репликацией, Sentinel и Cluster. Они решают разные задачи и накладывают разные ограничения — выбор зависит от того, какую именно боль нужно устранить.
Что чем решается
Базовая теория — в репликации (sync/async, lag, failover, split brain, кворум) и шардинге (shard key, resharding).
- Репликация: полная копия данных на репликах. Можно разгрузить мастер чтениями и иметь «горячую» копию для переключения, но все записи по-прежнему идут в мастер.
- Sentinel: автоматический failover для схемы master-replica и обнаружение мастера для клиентов.
- Redis Cluster: встроенный шардинг — ключи распределены по слотам между несколькими мастерами + встроенный failover. Цена — ограничения на операции с несколькими ключами и требования к клиенту (MOVED/ASK и карта слотов).
Отдельная граница Redis: репликация по умолчанию асинхронная. Это влияет на свежесть чтений с реплик и на риск потери последних подтверждённых записей при failover — детали и инструменты снижения риска описаны в репликации.
Как выбрать
| Что хочется получить | Обычно выбирают | Цена/компромисс |
|---|---|---|
| Быстро, просто, данные восстановимы (кеш) | один Redis | единая точка отказа |
| Больше чтений + запасной узел | репликация | возможны устаревшие чтения; записи всё равно через мастер |
| Автоматический failover мастера | репликация + Sentinel | failover не мгновенный; возможна потеря последних записей |
| Данные/записи не умещаются в один узел | Redis Cluster | ограничения на multi-key атомарность; нужен cluster-aware клиент |
Если ключевая ценность — строгая сохранность подтверждённых записей, Redis требует аккуратного дизайна: либо дополнять запись WAIT/настройками кворума реплик, либо держать источник истины в другой СУБД, используя Redis как ускоритель.
Минимальные топологии
Master-replica + Sentinel: 1 master + 1–2 replicas + 3 Sentinel (Sentinel лучше держать на отдельных хостах/VM).
Cluster: минимально 3 masters + 3 replicas (по одной реплике на мастер), чтобы кластер мог пережить падение одного мастера и сохранить покрытие слотов.
Sources
- Redis Documentation: Replication, Sentinel, Cluster (Redis OSS 8.2). https://redis.io/docs/
- Redis Cluster specification. https://redis.io/docs/reference/cluster-spec/