Redis Cluster vs Sentinel: высокодоступность кэша и сессий без сюрпризов

Если вы храните кэш и сессии в Redis, вопрос высокой доступности рано или поздно встанет остро. Один экземпляр Redis — это просто, быстро, но без отказоустойчивости. Два основных инструмента для продакшена — Sentinel и Redis Cluster. На бумаге оба решают HA, но делают это принципиально по-разному, что критично для производительности, консистентности и сложности эксплуатации.

Задача: кэш и PHP-сессии без сюрпризов

Для кэша важны скорость, предсказуемая деградация и простые стратегии инвалидации. Для сессий PHP важны надёжность, блокировки, минимальные таймауты при сбоях и отсутствие потерь. В обоих случаях необходимы четкие правила failover и понятная модель консистентности — а также осознанный выбор между вертикальным масштабированием и шардированием.

Если вы выбираете инфраструктуру под Redis, чаще всего удобнее развернуть узлы на VDS: будет изоляция, приватные сети и контроль над ядрами/дисками, что важно для прогнозируемых задержек и восстановления.

Коротко о моделях HA в Redis

• Одиночный Redis + резерв (реплика) без авто-failover. Подходит для разработки, не для продакшена.
• Redis + Sentinel: один ведущий (primary) и реплики, авто-переключение ведущего при сбое, клиенты узнают адрес нового ведущего через Sentinel.
• Redis Cluster: несколько ведущих, шардинг по слотам, встроенный механизм обнаружения и авто-failover по кворуму.

Дальше сравним последние два, так как они действительно решают задачу HA.

Как работает Redis Sentinel

Sentinel — это внешний контрольный слой, который следит за ведущим и репликами. Когда ведущий недоступен, Sentinels (их должно быть минимум три для кворума) выбирают новую роль для подходящей реплики и объявляют её ведущим. Клиенты, умеющие работать с Sentinel, запрашивают у него текущую роль ведущего и переподключаются.

Плюсы Sentinel

• Простая логика: один набор данных целиком живёт на одном ведущем. Нет шардирования и связанных ограничений.
• Умеренная сложность эксплуатации: понятная топология 1 primary + N replicas и 3+ Sentinel для кворума.
• Хорош для сессий: простая модель ключей, сессионная блокировка реализуется без распределённых транзакций.
• Прозрачность для кэша: все операции доступны, нет ограничений на многоключевые операции.

Минусы Sentinel

• Масштабирование записей и объёма данных ограничено одним ведущим узлом.
• Есть окно недоступности на время failover (обычно секунды-десятки секунд в зависимости от настроек и сети).
• Нужны клиенты с поддержкой Sentinel, иначе придётся городить прокси или переподключение вручную.

Для устойчивого кворума запускайте минимум три Sentinel на разных узлах, изолируйте их от общих точек отказа и тестируйте переключения в часы минимальной нагрузки.

Ключевые настройки Sentinel и Redis

Минимальный пример настроек Sentinel для кластера из одного ведущего и двух реплик. Подставьте свои IP, порты и пароль.

sentinel monitor mymaster 10.0.0.1 6379 2
sentinel down-after-milliseconds mymaster 5000
sentinel failover-timeout mymaster 60000
sentinel parallel-syncs mymaster 1
sentinel auth-pass mymaster yourStrongPassword
sentinel announce-ip 10.0.0.10
sentinel announce-port 26379
protected-mode yes

Фрагменты конфигов Redis-узлов.

# На ведущем
bind 0.0.0.0
port 6379
protected-mode yes
requirepass yourStrongPassword
appendonly yes
appendfsync everysec
save 900 1
save 300 10
save 60 10000
replica-priority 100
# Для безопасности можно отключить опасные команды
rename-command FLUSHALL ""
rename-command FLUSHDB ""

# На реплике
bind 0.0.0.0
port 6379
protected-mode yes
requirepass yourStrongPassword
masterauth yourStrongPassword
replicaof 10.0.0.1 6379
appendonly yes
appendfsync everysec
replica-priority 100

Важные моменты эксплуатации:

• Подбирайте down-after-milliseconds под вашу сеть. Часто 3000–10000 мс дают разумный баланс между чувствительностью и ложными срабатываниями.
• Общее время failover обычно укладывается в 10–30 секунд. Заложите это в таймауты приложений.
• Отключите опасные команды или ограничьте их ACL. Продумайте политику maxmemory-policy с TTL для кэш-ключей.
• Используйте AOF с appendfsync everysec для сокращения потерь; оцените стоимость fsync и I/O.

Как работает Redis Cluster

Redis Cluster делит пространство ключей на 16384 slots и распределяет их по нескольким ведущим узлам. У каждого ведущего есть реплика. Клиент должен быть cluster-aware: уметь следовать редиректам MOVED и ASK, и поддерживать таблицу слотов. Для отказоустойчивости требуется кворум среди ведущих и доступность реплики для быстрой замены.

Плюсы Cluster

• Горизонтальное масштабирование объёма и пропускной способности записи.
• Встроенный failover и распределённое обнаружение без внешних Sentinel.
• Онлайн-ресхардинг: можно перераспределять слоты между узлами.

Минусы Cluster

• Клиент обязан поддерживать Cluster, иначе будут ошибки MOVED и ASK.
• Ограничения на многоключевые операции: большинство из них работает только если все ключи в одном слоте (используйте hash-tags).
• Сложнее отлаживать, больше узлов для минимальной устойчивости (часто 3 ведущих + 3 реплики).

Ключевые настройки Cluster и начальная инициализация

Фрагмент redis.conf для узла кластера:

bind 0.0.0.0
port 6379
protected-mode yes
requirepass yourStrongPassword
masterauth yourStrongPassword
appendonly yes
appendfsync everysec
cluster-enabled yes
cluster-config-file nodes.conf
cluster-node-timeout 5000
rename-command FLUSHALL ""
rename-command FLUSHDB ""

Создание кластера из 3 ведущих и 3 реплик (пример, запустите на любом узле):

redis-cli --cluster create 10.0.0.1:6379 10.0.0.2:6379 10.0.0.3:6379 10.0.0.4:6379 10.0.0.5:6379 10.0.0.6:6379 --cluster-replicas 1

Обратите внимание: для записи нужен кворум ведущих. Потеря большинства приведёт к отказу от записи до восстановления. Это защищает от раскола сети, но накладывает инфраструктурные требования.

PHP-сессии: где меньше рисков

PHP-сессии критичнее к небольшим паузам при переключениях и к консистентности. Чаще всего лучше подходит Sentinel-модель: один ведущий и одна-две реплики. Это упрощает блокировки (session locking), не требует cluster-aware сессионного клиента, и лишено ограничений по многоключевым операциям внутри одной сессии.

Если вы всё же используете Redis Cluster для сессий, убедитесь, что выбранный session handler поддерживает Cluster и помещает ключи блокировки и данные одной сессии в один слот (общий hash-tag). Иначе возможны ошибки или деградация при блокировках. Подробно про практику — в материале о Redis для PHP-сессий и объектного кэша: Redis для PHP-сессий и объектного кэша: настройка и подводные камни.

Рекомендации по настройке PHP с phpredis

Пример для Sentinel (сессионный обработчик redis):

session.save_handler = redis
session.save_path = "sentinel:10.0.0.10:26379?master=mymaster&auth=yourStrongPassword&timeout=1.0&read_timeout=1.0&retry_interval=50"
redis.session.locking_enabled = 1
redis.session.lock_retries = 15
redis.session.lock_wait_time = 10000

Пример для Redis Cluster (сессионный обработчик rediscluster):

session.save_handler = rediscluster
session.save_path = "seed[]=10.0.0.1:6379&seed[]=10.0.0.2:6379&seed[]=10.0.0.3:6379&timeout=1.0&read_timeout=1.0"
redis.session.locking_enabled = 1
redis.session.lock_retries = 15
redis.session.lock_wait_time = 10000

• Установите таймауты PHP так, чтобы они перекрывали окно failover Redis (например, на уровне драйвера и HTTP-таймаутов).
• Проверьте блокировки под нагрузкой. Неадекватно длинные lock_wait_time замораживают пул PHP-FPM.
• Используйте отдельную БД Redis для сессий, чтобы изолировать их от шумного кэша.

Кэш: когда Sentinel, когда Cluster

Если набор кэша помещается в память одного сервера с запасом (скажем, до 60–70% RAM с учётом фрагментации), Sentinel проще и надёжнее. Он сохранит все возможности Redis, упрощает отладку и миграции, позволит использовать читатели-реплики для тяжёлых чтений.

Если объём кэша или интенсивность записи растёт быстрее, чем масштабируется один узел, переходите к Cluster. Это даёт шардирование, но потребует дисциплины в ключах и инструментов для управления слотами. Учтите, что некоторые шаблоны инвалидации, требующие многоключевых операций, придётся адаптировать (hash-tags, батчи по ключам одного слота, SCAN вместо KEYS).

Практика ключей и TTL

• Всегда задавайте TTL кэш-ключам. Не полагайтесь на ручной FLUSH*, лучше используйте версионирование namespace в ключе.
• Не используйте KEYS * в продакшене. Для обхода — SCAN.
• В Cluster группируйте зависимые ключи hash-tag’ом: например, product:{123}:meta, product:{123}:price.

Производительность и задержки

Sentinel не добавляет оверхедов на путь данных, он влияет только при сбоях. В Cluster есть накладные расходы на редиректы и обновление карты слотов на стороне клиента, но в штатном режиме они невелики. Практически значимы:

• Размер пакетов и пайплайнинг: используйте пайплайны для массовых операций.
• Включение TLS: учитывайте рост CPU и добавочную задержку, если включаете шифрование.
• Диск и AOF: appendfsync everysec даёт неплохой баланс, но следите за очередями записи.

Если нужен прогнозируемый CPU и сетевой стек под большую RPS-нагрузку, посмотрите сравнение производительности современных инстансов: ARM VDS для PHP и Node: производительность и экономия.

Сценарии и матрица выбора

• Простота и стоимость: Sentinel проще, меньше узлов минимум для HA.
• Масштабируемость записи и объёма: Cluster выигрывает за счёт горизонтального шардинга.
• Окно failover: у обоих есть пауза, в Cluster часто короче, но зависит от сети и кворума.
• Ограничения по операциям: у Sentinel нет, у Cluster есть (многоключевые операции, транзакции, Lua — в рамках слота).
• Клиенты: Sentinel требует поддержку Sentinel, Cluster — поддержку Cluster. Для PHP сессий Sentinel обычно беспроблемнее.
• Устойчивость к расколу сети: Cluster при потере кворума блокирует запись; в Sentinel нужна аккуратная настройка кворума и сетей.

Облачный VDS-сервер в России

Аренда виртуальных серверов с моментальным развертыванием инфраструктуры от 195₽ / мес

Подробнее

Типовые ошибки и как их избежать

• Один Sentinel в продакшене. Нужны 3+ узла Sentinel для кворума.
• Нет тестов failover. Регулярно проводите учения с измерением SLO.
• Неправильные таймауты PHP/драйвера. Синхронизируйте их с down-after-milliseconds и реальным временем failover.
• Использование KEYS и FLUSHALL в рабочее время. Заменяйте на SCAN и инвалидацию namespace.
• Отсутствие AOF/резервных копий. Минимизируйте окно потерь, проверяйте восстановление.
• Игнорирование политики памяти. Настройте maxmemory и maxmemory-policy под ваши паттерны.

Чек-лист развёртывания

• Определитесь: нужен шардинг прямо сейчас или нет. Если нет — начинайте с Sentinel.
• Минимум 3 Sentinel на разных узлах; для Cluster — минимум 3 ведущих и 3 реплики.
• Настройте AOF, резервное копирование и мониторинг задержек, репликации и RDB/AOF.
• Проверьте клиентские драйверы на поддержку Sentinel/Cluster и корректные таймауты.
• Для PHP-сессий включите session locking, выделите отдельную БД и задайте TTL.
• Проведите плановые учения по отказам и замерам времени восстановления.

Итог

Если ваша задача — надёжные PHP-сессии и кэш, который помещается в один узел с запасом, Sentinel даст высокую доступность с минимальной сложностью и без функциональных ограничений. Если же растёт объём и нагрузка, и вам нужен горизонтальный масштаб, берите Redis Cluster, но закладывайте время на клиентскую поддержку, дисциплину ключей и операционные практики. Главное — заранее измерьте окно failover, приведите таймауты приложений к единому знаменателю и регулярно проверяйте сценарии сбоев. Тогда высокодоступный Redis не будет источником сюрпризов.