Как работает репликация и высокая доступность в Redis?

Question

Accepted Answer

Redis обеспечивает **высокую доступность** через **репликацию** (реплики копируют данные), **Redis Sentinel** (мониторинг автоматического переключения) и **Redis Cluster** (шардирование + репликация). Понимание этих механизмов важно для надёжного запуска Redis в production.

## Репликация — primary и replicas

```text
PRIMARY (master) → handles writes; asynchronously replicates data to replicas
REPLICAS (slaves) → copies of the primary's data; can serve READS (read scaling)

Write → Primary → async replication → Replicas (eventually consistent)
  ✓ Redundancy (replicas have copies) + read scaling (reads offloaded to replicas)
  ✗ Replication is ASYNC → a small lag; a failover could lose very recent writes
```

Replicas асинхронно копируют данные primary — обеспечивая избыточность и масштабирование чтения (чтения могут идти к репликам), хотя с небольшой задержкой репликации.

## Redis Sentinel — автоматическое переключение

```text
Replication alone doesn't auto-recover if the PRIMARY fails. REDIS SENTINEL adds:
  → MONITORING — Sentinels watch the primary and replicas
  → AUTOMATIC FAILOVER — if the primary fails, Sentinels elect a replica as the new primary
  → SERVICE DISCOVERY — clients ask Sentinel for the current primary address
→ Sentinel provides high availability (auto-failover) for a non-clustered setup.
  (Run multiple Sentinels — a majority must agree — to avoid false failovers.)
```

**Sentinel** мониторит установку и выполняет **автоматическое переключение** (повышение replica, если primary отказывает) — превращая отказ primary в кратковременный перерыв вместо полного сбоя.

## Redis Cluster — шардирование + HA

```text
REDIS CLUSTER → for scaling beyond one server's memory AND high availability:
  → SHARDS data across multiple primaries (each holds a subset via hash slots, 16384 total)
  → each primary has replicas (HA — a replica takes over if its primary fails)
  → scales horizontally (more memory/throughput) + built-in failover
→ Use Cluster when data exceeds one node's RAM or you need to scale writes.
```

## Почему это важно

Понимание репликации и высокой доступности Redis важно для **надёжного запуска Redis в production**, поэтому это ценные знания senior-уровня для production-развёртываний Redis.

Поскольку Redis часто хранит важные данные (кеши, потеря которых вызывает скачки нагрузки, сессии, очереди), обеспечение доступности и избыточности имеет значение. **Репликация** (replicas асинхронно копируют primary) формирует основу — избыточность (replicas хранят копии) и масштабирование чтения (разгрузка чтений на replicas) — но понимание её **асинхронной природы** (небольшая задержка, потенциальная потеря совсем свежих записей при переключении) важно для рассуждений о консистентности. **Redis Sentinel** критична для высокой доступности в non-clustered setup: она добавляет **мониторинг и автоматическое переключение** (повышение replica при отказе primary) плюс service discovery, превращая отказ primary в кратковременный перерыв вместо сбоя — необходимо для систем, которые должны оставаться доступными (и запуск нескольких Sentinels для большинственного согласия предотвращает ложные переключения). **Redis Cluster** решает как масштабирование, так и HA: **шардирование данных по нескольким primaries** (через hash slots, масштабирование за пределы памяти и пропускной способности одного сервера) с репликами для переключения — необходимо, когда данные превышают RAM одного узла или запись должна масштабироваться.

Понимание выбора (Sentinel для HA одного датасета, Cluster для шардирования + HA в масштабе) отражает звуковое операционное суждение.

Поскольку production Redis должен быть доступен и может потребоваться масштабирование, и поскольку репликация (избыточность/масштабирование чтения), Sentinel (автоматическое переключение) и Cluster (шардирование + HA) — механизмы Redis для надёжности и масштаба, понимание репликации и высокой доступности Redis — это важные знания senior-уровня для надёжного развёртывания Redis, часто критичная production-проблема и тема, демонстрирующая понимание запуска Redis как надёжной части инфраструктуры, а не единой точки отказа.