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

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

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

    Содержание

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

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

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

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

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

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

    Операции увеличения масштаба

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

    Выделение памяти экземпляра ≥ Максимальная рабочая память

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

    Операции уменьшения масштаба

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

    Выделение памяти экземпляра ≥ (Максимальная память данных остающихся шардов + Память миграции данных) ÷ 0.8

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

    Процедура

    CLI
    Web Console

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

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

    Чтобы следить за ходом операции масштабирования:

    $ kubectl -n default get redis c6 -w

    После отправки изменения конфигурации шардов система переводит экземпляр в состояние Балансировка данных и самостоятельно управляет процессом миграции слотов. Находясь в этом состоянии, все изменения экземпляра, кроме удаления, ограничены.

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

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

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

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

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

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

    Длительность операции

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

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

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