Yandex Cloud
  • Сервисы
  • Решения
  • Почему Yandex Cloud
  • Сообщество
  • Тарифы
  • Документация
  • Связаться с нами
Подключиться
Language / Region
Проект Яндекса
© 2023 ООО «Яндекс.Облако»
Yandex Managed Service for Redis
  • Начало работы
  • Пошаговые инструкции
    • Все инструкции
    • Информация об имеющихся кластерах
    • Создание кластера
    • Изменение настроек кластера и базы данных
    • Подключение к базе данных
      • Подготовка к подключению
      • Подключение к нешардированному кластеру
      • Подключение к шардированному кластеру
    • Остановка и запуск кластера
    • Обновление версии Redis
    • Управление хостами кластера
    • Управление шардами
    • Управление резервными копиями
    • Переключение мастера
    • Мониторинг состояния кластера и хостов
    • Просмотр логов кластера
    • Удаление кластера
  • Практические руководства
    • Все сценарии
    • Хранение сессий PHP в Managed Service for Redis
    • Миграция базы данных в Managed Service for Redis
  • Концепции
    • Взаимосвязь ресурсов сервиса
    • Классы хостов
    • Сеть в Managed Service for Redis
    • Шардирование
    • Резервные копии
    • Репликация и отказоустойчивость
    • Поддерживаемые клиенты
    • Управление памятью в Managed Service for Redis
    • Доступные команды Managed Service for Redis
    • Квоты и лимиты
    • Типы диска
    • Техническое обслуживание
    • Настройки Redis
  • Управление доступом
  • Правила тарификации
    • Действующие правила
    • Архив
      • До 1 февраля 2020 года
  • Справочник API
    • Аутентификация в API
    • gRPC (англ.)
      • Overview
      • BackupService
      • ClusterService
      • ResourcePresetService
      • OperationService
    • REST (англ.)
      • Overview
      • Backup
        • Overview
        • get
        • list
      • Cluster
        • Overview
        • addHosts
        • addShard
        • backup
        • create
        • delete
        • deleteHosts
        • deleteShard
        • get
        • getShard
        • list
        • listBackups
        • listHosts
        • listLogs
        • listOperations
        • listShards
        • move
        • rebalance
        • rescheduleMaintenance
        • restore
        • start
        • startFailover
        • stop
        • streamLogs
        • update
        • updateHosts
      • ResourcePreset
        • Overview
        • get
        • list
      • Operation
        • Overview
        • get
  • История изменений
  • Вопросы и ответы
    • Общие вопросы
  1. Концепции
  2. Шардирование

Шардирование в Managed Service for Redis

Статья создана
Yandex Cloud
  • Преимущества шардирования
  • Структура Redis Cluster
  • Отказоустойчивость
  • Масштабирование

Шардирование в Managed Service for Redis реализовано с помощью Redis Cluster.

Преимущества шардирования

Шардирование предлагает распределить нагрузку по хостам базы данных — это позволяет преодолеть ограничения ресурсов одного сервера, что особенно актуально при больших объемах данных или необходимости в интенсивных вычислениях.

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

Более подробно шардирование баз Redis рассмотрено в документации Redis.

Структура Redis Cluster

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

В каждом кластере находятся 16348 хеш-слота, которые равномерно распределяются между шардами. Слоты определяют набор данных, который хранится в том или ином шарде.

Отказоустойчивость

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

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

Чтобы обеспечить стабильную работу кластера, нужно создать минимум три хоста-мастера в разных зонах доступности, у каждого из которых будет по одной реплике. Мастеры и их реплики должны находиться в разных зонах доступности.

Масштабирование

При необходимости горизонтального масштабирования кластера, в него можно добавлять новые шарды.

Новый шард создается без хеш-слотов. Чтобы перераспределить данные, необходимо выполнить ребалансировку кластера. После этого на новый шард переместится часть уже существующих слотов.

Перемещение слотов между шардами не требует остановки работы кластера. Если клиент отправил запрос к мастеру на данные, которые были перемещены на другой шард, этот запрос будет переадресован на новый шард, куда переместились данные. Сами хосты не проксируют запросы, а только перенаправляют клиента на правильный шард.

Managed Service for Redis позволяет создать от 3 до 10 шардов, каждый из которых может включать в себя разное количество хостов. Минимальное количество хостов в шарде зависит от выбранного типа диска.

Подробнее об ограничениях на количество хостов в шарде см. в разделе Квоты и лимиты в Managed Service for Redis.

Была ли статья полезна?

Language / Region
Проект Яндекса
© 2023 ООО «Яндекс.Облако»
В этой статье:
  • Преимущества шардирования
  • Структура Redis Cluster
  • Отказоустойчивость
  • Масштабирование