Alauda Cache Service for Redis OSS
  • Русский

    • Масштабирование шардов в режиме кластера

    Архитектура Redis Cluster обеспечивает горизонтальное масштабирование за счёт распределения данных по нескольким шардам. По мере изменения требований к нагрузке может потребоваться корректировка количества шардов для оптимизации производительности, использования ресурсов и распределения данных. В этом документе изложены технические аспекты, требования к ресурсам и рекомендации по выполнению операций масштабирования шардов.

    Содержание

    Предварительные условияТребования к ресурсамОперации масштабирования вверхОперации масштабирования внизПроцедураПодключение клиентов во время масштабированияПродолжительность операции

    Предварительные условия

    Перед изменением конфигурации шардов в Redis Cluster необходимо убедиться в выполнении следующих условий:

    • Состояние работы: кластер должен находиться в стабильном состоянии Running, все узлы должны функционировать корректно.
    • Доступность ресурсов: в кластере должно быть достаточно памяти для перераспределения данных в процессе масштабирования.
    • Окно обслуживания: планируйте операции масштабирования в периоды низкой нагрузки, чтобы минимизировать возможное влияние на сервис.
    • Пропускная способность сети: убедитесь в наличии достаточной пропускной способности сети между узлами Redis для эффективной миграции данных.
    • Стабильность инфраструктуры: обеспечьте стабильность инфраструктуры, чтобы избежать сбоев узлов во время масштабирования, что может повлиять на целостность данных.

    Требования к ресурсам

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

    ТерминОпределениеПримечания
    Data MemoryФактический объём памяти, занимаемый набором данных RedisОтслеживается с помощью команды info memory; это значение меняется по мере оптимизации памяти и сборки мусора Redis
    Maximum Data MemoryМаксимальное потребление памяти, зафиксированное на всех узлах RedisИспользуется как ориентир при планировании ёмкости
    Maximum Running MemoryMaximum Data Memory ÷ 0.8Коэффициент (0.8) отражает рекомендуемое соотношение между maxmemory и общей выделенной памятью экземпляра; меньшие коэффициенты увеличивают запас, но снижают эффективность использования памяти
    Migration Data MemoryСовокупный объём данных с выводимых из эксплуатации шардовПри операциях уменьшения количества шардов эти данные необходимо перераспределить по оставшимся шардом

    Операции масштабирования вверх

    При увеличении количества шардов каждый экземпляр должен удовлетворять условию:

    Выделенная память экземпляра ≥ Maximum Running Memory

    Эта формула гарантирует успешное добавление шардов при сбалансированном распределении данных. В средах с несбалансированными данными или наличием BigKeys требуется дополнительное планирование ресурсов, так как миграция данных может сконцентрировать нагрузку на отдельных шардах.

    Операции масштабирования вниз

    При уменьшении количества шардов каждый оставшийся экземпляр должен удовлетворять условию:

    Выделенная память экземпляра ≥ (Maximum Data Memory оставшихся шардов + Migration Data Memory) ÷ 0.8

    Эта формула учитывает перераспределение данных с выводимых шардов. В отличие от масштабирования вверх, операции уменьшения количества шардов предъявляют жёсткие требования к ресурсам для обеспечения работы в условиях возможной концентрации данных, даже при несбалансированном распределении.

    Процедура

    CLI
    Web Console

    Масштабирование шардов управляется через поле spec.replicas.cluster.shard в пользовательском ресурсе Redis (подробные спецификации параметров см. в API documentation).

    # Настроить кластер на использование 4 шардов
$ kubectl -n default patch redis c6 --type=merge --patch='{"spec": {"replicas":{"cluster":{"shard": 4}}}}'

    Для отслеживания прогресса операции масштабирования:

    $ kubectl -n default get redis c6 -w

    После отправки изменения конфигурации шардов система переводит экземпляр в состояние Data Balancing и самостоятельно управляет процессом миграции слотов. В этом состоянии все изменения экземпляра, кроме удаления, запрещены.

    Подключение клиентов во время масштабирования

    Во время перераспределения шардов миграция слотов Redis влияет на обработку клиентских запросов следующим образом:

    1. Когда клиент запрашивает доступ к ключу в слоте, помеченном для миграции:

      • Если ключ уже мигрировал на целевой шард, Redis возвращает ошибку перенаправления MOVED
      • Если ключ ещё не мигрировал, запрос обрабатывается исходным шардом

    2. Клиенты, поддерживающие работу с Redis Cluster, автоматически обрабатывают ошибки перенаправления, повторно отправляя запрос на нужный шард

    Рекомендация по производительности: масштабирование шардов в периоды высокой нагрузки может удвоить фактический объём клиентских запросов из-за перенаправлений, что потенциально создаёт сетевые заторы. По возможности планируйте операции масштабирования на периоды сниженной активности.

    Продолжительность операции

    Время, необходимое для завершения операций масштабирования шардов, зависит от множества факторов:

    • Общий объём данных, подлежащих перераспределению
    • Пропускная способность сети между узлами
    • Характеристики ресурсов экземпляров
    • Наличие BigKeys, требующих миграции
    • Интенсивность текущей нагрузки

    Обычно операции масштабирования шардов занимают от 20 минут до нескольких часов. Большие объёмы данных и сложные схемы миграции увеличивают продолжительность.