Redis Cluster

Redis Cluster — это распределённая реализация СУБД Redis, обеспечивающая автоматическое шардирование данных, высокую доступность и горизонтальное масштабирование за счёт децентрализованной архитектуры без единой точки отказа. В отличие от классического одноузлового Redis, кластер позволяет хранить объёмы данных, превышающие оперативную память одного сервера, и обрабатывать запросы при отказе отдельных узлов.

Архитектура и принципы работы

Redis Cluster построен на основе децентрализованной топологии «каждый с каждым» (full mesh). Все узлы кластера обмениваются информацией через протокол gossip, что исключает необходимость в центральном координаторе. Кластер использует следующие ключевые механизмы:

Шардирование данных

Данные распределяются по 16384 хеш-слотам (hash slots). Каждому ключу ставится в соответствие один из слотов на основе CRC16-хеша от имени ключа, по модулю 16384. Слоты равномерно распределяются между мастер-узлами кластера. Например, в кластере из трёх мастеров каждый может обслуживать примерно по 5461 слоту.

При добавлении или удалении узла слоты перераспределяются между ними. Этот процесс называется решардингом (resharding) и может выполняться без остановки обслуживания. Клиентские библиотеки перенаправляют запросы на новые узлы автоматически.

Высокая доступность

Для обеспечения отказоустойчивости каждый мастер-узел может иметь от одного до нескольких реплик (replica nodes). Реплики являются точными копиями мастера и синхронизируются асинхронно. Если мастер становится недоступным (потеря связи, выход из строя), реплика автоматически повышается до мастера по решению кластерного консенсуса.

Процесс выбора нового мастера (failover) инициируется, когда большинство мастеров в кластере подтверждают недоступность узла. Реплика с наилучшим состоянием данных (наибольший replication offset) становится новым мастером. Время переключения обычно составляет несколько секунд.

Gossip-протокол

Узлы кластера постоянно обмениваются сообщениями о своём состоянии (ping/pong) через порт, смещённый на 10000 от порта данных (например, 16379 для порта данных 6379). Gossip-протокол позволяет каждому узлу знать топологию кластера, состояние других узлов и распределение слотов. Это обеспечивает децентрализованное обнаружение отказов и обновление конфигурации.

Классификация узлов

В Redis Cluster выделяют несколько ролей узлов:

• Мастер (master) — основной узел, обслуживающий запросы на чтение и запись для своего набора слотов. Каждый слот обслуживается ровно одним мастером.
• Реплика (replica) — резервный узел, синхронизирующий данные с мастером. Может обслуживать запросы на чтение (если настроено), но не участвует в записи.
• Наблюдатель (sentinel) — в контексте Redis Cluster не используется; Sentinel — отдельный компонент для мониторинга и отказоустойчивости классического Redis. В кластере роль Sentinel выполняет сам кластер.

Установка и конфигурация

Для развёртывания Redis Cluster требуется не менее трёх мастер-узлов (минимальная конфигурация для отказоустойчивости). Каждый узел запускается с включённым режимом кластера в конфигурационном файле:

`` cluster-enabled yes cluster-config-file nodes.conf cluster-node-timeout 5000 ``

После запуска всех узлов кластер инициализируется с помощью утилиты redis-cli --cluster create или через API команд CLUSTER MEET, CLUSTER ADDSLOTS. Пример создания кластера из трёх мастеров и трёх реплик:

``bash redis-cli --cluster create 192.168.1.1:6379 192.168.1.2:6379 192.168.1.3:6379 \ --cluster-replicas 1 ``

Клиентская поддержка

Клиентские библиотеки для работы с Redis Cluster должны реализовывать протокол перенаправления запросов. Основные механизмы:

• MOVED — постоянное перенаправление: клиент получает сообщение, что слот переехал на другой узел. Клиент кеширует новую карту слотов.
• ASK — временное перенаправление: используется во время миграции слотов. Клиент должен повторить запрос на указанном узле с флагом ASKING.
• CLUSTER SLOTS — команда для получения полной карты распределения слотов от любого узла.

Популярные клиенты (redis-py, ioredis, Jedis) поддерживают кластерный режим автоматически.

Применение

Redis Cluster применяется в системах, требующих высокой пропускной способности и отказоустойчивости:

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

Ограничения и особенности

• Транзакции — поддерживаются только в пределах одного слота (ключа). Мультиключевые транзакции с ключами из разных слотов не выполняются.
• Lua-скрипты — аналогично, скрипты могут работать только с ключами, принадлежащими одному слоту.
• Асинхронная репликация — возможна потеря данных при отказе мастера до синхронизации с репликой (окно потери — несколько миллисекунд).
• Сложность управления — требуется мониторинг состояния слотов, решардинг, настройка времени таймаута.
• Не поддерживает — команды MIGRATE, SORT (в некоторых режимах), KEYS (сканирование всех ключей неэффективно).

Интересные факты

• Размер хеш-слота (16384) выбран как компромисс между производительностью вычисления CRC16 и количеством узлов в кластере (рекомендуется до 1000 узлов).
• Redis Cluster не использует распределённый консенсус (Raft, Paxos) — failover основан на gossip-протоколе и голосовании мастеров.
• Первая стабильная версия Redis Cluster появилась в версии 3.0 (2015 год).
• Для миграции данных между кластерами используется утилита redis-cli --cluster import.

Источники

• Официальная документация Redis Cluster (redis.io/docs/latest/operate/oss_and_stack/management/scaling/)
• Redis in Action (Josiah L. Carlson, 2013)
• Redis Cluster Specification (antirez.com/news/49)
• Документация Redis 7.0 (redis.io/docs/latest/)