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

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

## Назначение

Redis Sentinel — система мониторинга и автоматического failover для Redis. Обеспечивает высокую доступность без ручного вмешательства при отказе мастера.

## Топология

```text
┌───────────┐     репликация     ┌───────────┐
│  Мастер   │ ─────────────────► │  Реплика  │
└───────────┘                    └───────────┘
      ▲                                ▲
      │          мониторинг            │
┌─────┴──────────────────────────┐    │
│  Sentinel 1  Sentinel 2  Sentinel 3 │
└────────────────────────────────┘

```

Минимальная рекомендуемая конфигурация: **3 Sentinel-процесса** (нечётное число для кворума).

## Кворум (quorum)

Кворум — минимальное количество Sentinel-узлов, которые должны согласиться, что мастер недоступен, прежде чем начнётся выборы нового мастера.

<table id="bkmrk-%D0%9F%D0%B0%D1%80%D0%B0%D0%BC%D0%B5%D1%82%D1%80-%D0%A0%D0%B5%D0%BA%D0%BE%D0%BC%D0%B5%D0%BD%D0%B4%D0%B0%D1%86%D0%B8"><thead><tr><th>Параметр</th><th>Рекомендация</th></tr></thead><tbody><tr><td>Число Sentinel</td><td>3</td></tr><tr><td>Кворум</td><td>2</td></tr></tbody></table>

Если кворум не достигнут, failover не выполняется — защита от split-brain.

## Выборы мастера

1. Sentinel-ы обнаруживают, что мастер не отвечает в течение `down-after-milliseconds`.
2. Каждый Sentinel помечает мастер как **SDOWN** (субъективно недоступен).
3. Когда `quorum` Sentinel-ов помечают мастер — он становится **ODOWN** (объективно недоступен).
4. Один из Sentinel-ов избирается **лидером** через алгоритм Raft.
5. Лидер выбирает лучшую реплику для повышения до мастера.

## Критерии выбора новой реплики

- Реплика должна быть online.
- Предпочитается реплика с наименьшим `slave-priority`.
- При равном приоритете — с наибольшим `replication_offset` (меньше отставание).
- При равном offset — с наименьшим runid (детерминированный выбор).

## Процесс failover

```text
1. Лидер отправляет SLAVEOF NO ONE выбранной реплике → она становится мастером
2. Остальные реплики переключаются на нового мастера (SLAVEOF <new-master>)
3. Клиенты получают уведомление через Pub/Sub или переспрашивают адрес мастера
4. Старый мастер (после восстановления) становится репликой нового

```

## Взаимодействие клиентов

Клиент подключается к Sentinel для получения адреса текущего мастера:

```text
SENTINEL get-master-addr-by-name <master-name>
→ возвращает IP:PORT актуального мастера

```

Redis-клиенты с поддержкой Sentinel (Jedis, StackExchange.Redis, redis-py) делают это автоматически.

## Роль Redis Sentinel в кластере ПринтМенеджера

Redis используется в кластере Принтум для:

- хранения пользовательских сессий;
- очередей заданий между узлами ПринтМенеджера;
- кэширования данных конфигурации.

Redis Sentinel обеспечивает автоматическое переключение при отказе Redis-мастера, чтобы оба узла ПринтМенеджера сохраняли доступ к данным.

В стандартной конфигурации разворачиваются **3 Sentinel-процесса** — по одному на каждый узел ПринтМенеджера (переменная REDIS\_SENTINEL\_LIST содержит 3 IP-адреса). TODO: уточнить точное значение кворума — в документации явно не указано. в стандартной конфигурации Принтум.