Масштабирование экземпляра Кэша Azure для Redis

  • Статья

Кэш Azure для Redis предлагает различные уровни, обеспечивающие гибкость в выборе размера и возможностей кэша. С помощью масштабирования можно изменить размер, уровень и количество узлов после создания экземпляра кэша в соответствии с потребностями приложения. В этой статье показано, как масштабировать кэш с помощью портал Azure, а также средств, таких как Azure PowerShell и Azure CLI.

Типы масштабирования

Существует два способа масштабирования экземпляра Кэш Azure для Redis:

  • Увеличение масштаба увеличивает размер виртуальной машины под управлением сервера Redis, добавляя больше памяти, виртуальные ЦП (виртуальные ЦП) и пропускную способность сети. Масштабирование также называется вертикальным масштабированием. Противоположность масштабирования — масштабирование вниз.

  • Масштабирование делит экземпляр кэша на несколько узлов с одинаковым размером, увеличением памяти, виртуальными ЦП и пропускной способностью сети с помощью параллелизации. Масштабирование также называется горизонтальным масштабированием или сегментированием. Противоположность масштабирования — масштабирование. В сообществе Redis масштабирование часто называется кластеризация.

Область доступности

Уровень "Базовый" и "Стандартный" Premium "Корпоративный" и Enterprise Flash
Увеличение масштаба Да Да Да (предварительная версия)
Вертикальное уменьшение масштаба Да Да Нет
Горизонтальное увеличение масштаба No Да Да (предварительная версия)
Масштабирование в No Да Нет

Выбор времени масштабирования

С помощью функций мониторинга Кэша Azure для Redis можно отслеживать работоспособность и производительность кэша. Используйте эти сведения для определения времени масштабирования кэша.

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

  • Загрузка сервера Redis
    • Высокая загрузка сервера Redis означает, что сервер не может поддерживать темпы запросов со всех клиентов. Так как сервер Redis — это единый потоковый процесс, обычно рекомендуется масштабировать, а не увеличивать масштаб. Масштабирование путем включения кластеризация помогает распределять нагрузки между несколькими процессами Redis. Масштабирование также помогает распространять шифрование TLS, расшифровку и подключение или отключение, ускоряя экземпляры кэша с помощью TLS.
    • Масштабирование по-прежнему может оказаться полезным при уменьшении нагрузки сервера, так как фоновые задачи могут воспользоваться преимуществами дополнительных виртуальных ЦП и освободить поток для основного процесса сервера Redis.
    • Уровни Enterprise и Enterprise Flash используют Redis Enterprise, а не открытый код Redis. Одним из преимуществ этих уровней является то, что процесс сервера Redis может воспользоваться несколькими виртуальными ЦП. Из-за этого увеличение масштаба и масштабирование на этих уровнях может оказаться полезным при уменьшении нагрузки сервера. Дополнительные сведения см. в разделе "Рекомендации по уровням Enterprise и Enterprise Flash" Кэш Azure для Redis.
  • Использование памяти
    • Высокий уровень использования памяти указывает, что размер данных слишком велик для текущего размера кэша. Рассмотрите возможность увеличения масштаба до размера кэша с большим объемом памяти. Масштабирование или масштабирование эффективно здесь.
  • Клиентские подключения
    • Каждый размер кэша имеет ограничение на количество поддерживаемых клиентских подключений. Если клиентские подключения близки к ограничению размера кэша, рассмотрите возможность масштабирования до большего уровня. Масштабирование не увеличивает количество поддерживаемых клиентских подключений.
    • Дополнительные сведения об ограничениях подключения по размеру кэша см. в Кэш Azure для Redis ценах.
  • Сеть Bandwidth
    • Если для сервера Redis превышена доступная пропускная способность, возможно, будет превышено время ожидания для запросов клиентов, так как сервер не будет успевать отправлять данные клиентам. С помощью метрик "Чтение из кэша" и "Запись в кэш" можно узнать, какая часть пропускной способности потребляется на стороне сервера. Если сервер Redis превышает доступную пропускную способность сети, следует рассмотреть возможность масштабирования или масштабирования до большего размера кэша с более высокой пропускной способностью сети.
    • Для кэшей корпоративного уровня с помощью политики кластера Enterprise масштабирование не увеличивает пропускную способность сети.
    • Дополнительные сведения о доступной пропускной способности сети в зависимости от размера кэша см. в статье Часто задаваемые вопросы по планированию Кэша Azure для Redis.

Дополнительные сведения о том, как определить оптимальную ценовую категорию кэша, см. в разделе Выбор подходящего уровня и статье Часто задаваемые вопросы по планированию Кэша Azure для Redis.

Примечание.

Дополнительные сведения о оптимизации процесса масштабирования см. в рекомендациях по масштабированию

Предварительные требования и ограничения масштабирования Кэш Azure для Redis

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

  • Перейти с более высокой ценовой категории на более низкую нельзя.
    • Вы не можете масштабировать кэш Enterprise или Enterprise Flash до любого другого уровня.
    • Ценовую категорию кэша Премиум нельзя изменить на категорию Стандартный или Базовый.
    • Ценовую категорию кэша Стандартный нельзя изменить на категорию Базовый.
  • Вы можете выполнить масштабирование кэша с уровня Базовый до уровня Стандартный, но вам не удастся одновременно с этим изменить размер кэша. Если требуется изменить размер, можно позднее выполнить операцию масштабирования до нужного размера.
  • Ценовую категорию кэша Базовый нельзя изменить сразу на уровень Премиум. Сначала перейдите с категории Базовый на категорию Стандартный, а затем — с категории Стандартный на категорию Премиум.
  • Вам не удастся выполнить масштабирование с большего размера до размера C0 (250 МБ) . Но вы можете и уменьшить масштаб до любого размера в той же ценовой категории, например со "Стандартный" C5 до "Стандартный" C1.
  • Вы не можете масштабировать кэш Уровня "Премиум", "Стандартный" или "Базовый" до кэша Enterprise или Enterprise Flash.
  • Невозможно масштабировать между Enterprise и Enterprise Flash.

Вы можете масштабировать или масштабировать с помощью следующих ограничений:

  • Горизонтальное масштабирование поддерживается только на уровнях Premium, Enterprise и Enterprise Flash.
  • Масштабирование поддерживается только на уровне "Премиум".
  • На уровне "Премиум" сначала необходимо включить кластеризация перед масштабированием.
  • На уровне "Премиум" поддерживается горизонтальное масштабирование до 10 сегментов. Поддержка до 30 сегментов доступна в предварительной версии. (Для кэшей с двумя реплика ограничение сегментов равно 20. При использовании трех реплика ограничение сегментов равно 15.)
  • Только уровни Enterprise и Enterprise Flash могут одновременно масштабироваться и масштабироваться.

Масштабирование уровней "Базовый", "Стандартный" и "Премиум"

Масштабирование вверх и вниз с помощью портал Azure

  1. Чтобы масштабировать кэш, перейдите к кэшу в портал Azure и выберите "Масштаб" в меню "Ресурс".

    Screenshot showing Scale on the resource menu.

  2. Выберите ценовую категорию в рабочей области и нажмите кнопку "Выбрать".

    Screenshot showing the Azure Cache for Redis tiers.

  3. Пока как кэш масштабируется до нового уровня, отображается уведомление Масштабирование кэша Redis.

    Screenshot showing the notification of scaling.

  4. После завершения масштабирования состояние меняется с Масштабирование на Работает.

Примечание.

При масштабировании кэша вверх или вниз с помощью портала maxmemory-reserved оба параметра maxfragmentationmemory-reserved автоматически масштабируются в пропорции к размеру кэша. Например, если для параметра maxmemory-reserved задано значение 3 ГБ, размер кэша равен 6 ГБ и вы масштабируете увеличивает кэш до 12 ГБ, параметры автоматически обновляются до 6 ГБ во время масштабирования. При масштабировании в сторону уменьшения происходят изменения в обратном направлении.

Увеличение и уменьшение масштаба с помощью PowerShell

Вы можете масштабировать экземпляры Кэш Azure для Redis с помощью PowerShell с помощью командлета Set-AzRedisCache при Sizeизменении или Sku изменения свойств. В следующем примере показано, как масштабировать кэш с именем myCache в 6 ГБ кэша на том же уровне.

   Set-AzRedisCache -ResourceGroupName myGroup -Name myCache -Size 6GB

Дополнительные сведения о масштабировании с помощью PowerShell см. в разделе Масштабирование Кэша Azure для Redis с помощью PowerShell.

Увеличение и уменьшение масштаба с помощью Azure CLI

Чтобы масштабировать экземпляры Кэш Azure для Redis с помощью Azure CLI, вызовите команду az redis update. sku.capcity Используйте свойство для масштабирования на уровне, например из кэша Standard C0 до standard C1:

az redis update --cluster-name myCache --resource-group myGroup --set "sku.capacity"="2"

Используйте свойства "sku.name" и "sku.family", чтобы увеличить масштаб до другого уровня, например из кэша standard C1 в кэш Premium P1:

az redis update --cluster-name myCache --resource-group myGroup --set "sku.name"="Premium" "sku.capacity"="1" "sku.family"="P"

Дополнительные сведения о масштабировании с помощью Azure CLI см. в разделе Изменение параметров существующего кэша Azure для Redis.

Примечание.

При масштабировании кэша вверх или вниз (например, с помощью PowerShell или Azure CLI) любой maxmemory-reserved или maxfragmentationmemory-reserved игнорируется в рамках запроса на обновление. Учитывается только изменение масштабирования. Эти параметры памяти можно обновить после завершения операции масштабирования.

Масштабирование и увеличение масштаба — уровни Enterprise и Enterprise Flash

Уровни Enterprise и Enterprise Flash могут масштабироваться и масштабироваться в одной операции. Другие уровни требуют отдельных операций для каждого действия.

Внимание

Уровни Enterprise и Enterprise Flash еще не поддерживают масштабирование или масштабирование в операциях.

Масштабирование с помощью портал Azure

  1. Чтобы масштабировать кэш, перейдите к кэшу в портал Azure и выберите "Масштаб" в меню "Ресурс".

    Screenshot showing Scale selected in the Resource menu for an Enterprise cache.

  2. Чтобы увеличить масштаб, выберите другой тип кэша и нажмите кнопку "Сохранить".

    Важно!

    Вы можете масштабироваться только в настоящее время. Невозможно уменьшить масштаб.

    Screenshot showing the Enterprise tiers in the working pane.

  3. Чтобы увеличить масштаб, увеличьте ползунок емкости . Емкость увеличивается на два. Это число отражает, сколько базовых узлов Redis Enterprise добавляются. Это число всегда является несколькими из двух для отображения узлов, добавляемых как для основных, так и для реплика сегментов.

    Важно!

    В настоящее время вы можете увеличить масштаб, увеличить емкость. Невозможно масштабировать.

    Screenshot showing Capacity in the working pane a red box around it.

  4. Пока как кэш масштабируется до нового уровня, отображается уведомление Масштабирование кэша Redis.

    Screenshot showing notification of scaling an Enterprise cache.

  5. После завершения масштабирования состояние меняется с Масштабирование на Работает.

Масштабирование с помощью PowerShell

Вы можете масштабировать экземпляры Кэш Azure для Redis с помощью PowerShell с помощью командлета Update-AzRedisEnterpriseCache. Свойство можно изменить Sku , чтобы масштабировать экземпляр вверх. Свойство можно изменить Capacity , чтобы масштабировать экземпляр. В следующем примере показано, как масштабировать кэш с именем myCache экземпляра Enterprise E20 (25 ГБ) с емкостью 4.

   Update-AzRedisEnterpriseCache -ResourceGroupName myGroup -Name myCache -Sku Enterprise_E20 -Capacity 4

Масштабирование с помощью интерфейса командной строки Azure

Чтобы масштабировать экземпляры Кэш Azure для Redis с помощью Azure CLI, вызовите команду az redisenterprise update. Свойство можно изменить sku , чтобы масштабировать экземпляр вверх. Свойство можно изменить capacity , чтобы масштабировать экземпляр. В следующем примере показано, как масштабировать кэш с именем myCache экземпляра Enterprise E20 (25 ГБ) с емкостью 4.

az redisenterprise update --cluster-name "myCache" --resource-group "myGroup" --sku "Enterprise_E20" --capacity 4

Масштабирование: часто задаваемые вопросы

В приведенном ниже списке представлены ответы на часто задаваемые вопросы о масштабировании кэша Azure для Redis.

Можно ли выполнять масштабирование кэша до уровня Премиум, с уровня Премиум до другого уровня или в пределах уровня Премиум?

  • Ценовую категорию кэша Премиум нельзя изменить на категорию Базовый или Стандартный.
  • Вы можете переходить от одной ценовой категории кэша Премиум к другой.
  • Ценовую категорию кэша Базовый нельзя изменить сразу на уровень Премиум. Сначала перейдите с категории Базовый на категорию Стандартный, а затем — с категории Стандартный на категорию Премиум.
  • Вы не можете масштабировать кэш Уровня "Премиум" до кэша Enterprise или Enterprise Flash.
  • Если вы включили кластеризация при создании кэша Premium, можно изменить размер кластера. Если кэш создан без кластеризации, ее можно будет настроить позже.

Нужно ли менять имя кэша и ключи доступа после масштабирования?

Нет, имя кэша и ключи не изменяются во время операции масштабирования.

Как работает масштабирование?

  • При масштабировании кэша "Базовый " до другого размера он завершает работу, а новый кэш подготавливается с помощью нового размера. В течение этого времени кэш недоступен и все данные в кэше теряются.
  • При масштабировании кэша уровня Базовый до уровня Стандартный система подготавливает реплику кэша. При этом данные будут скопированы из основного кэша в реплику кэша. Кэш остается доступным в процессе масштабирования.
  • При масштабировании кэша Standard, Premium, Enterprise или Enterprise Flash до другого размера один из реплика завершает работу и повторно создается на новый размер, а затем другой реплика выполняет отработку отказа до его повторной подготовки, аналогично процессу, который возникает во время сбоя одного из узлов кэша.
  • При горизонтальном масштабировании кластеризованного кэша система подготавливает новые сегменты и добавляет их в кластер серверов Redis. Затем она распределяет данные по всем сегментам.
  • При уменьшении масштаба в кластеризованном кэше система повторно распределяет данные по сегментам, а затем уменьшает размер кластера до требуемого количества сегментов.
  • В некоторых случаях, например при масштабировании или переносе кэша в другой кластер, базовый IP-адрес кэша может измениться. Запись DNS для кэша изменяется и является прозрачной для большинства приложений. Однако если вы используете IP-адрес для настройки подключения к кэшу или настройки групп безопасности сети или брандмауэров, разрешающих трафик в кэш, ваше приложение может столкнуться с проблемами при подключении через некоторое время после обновления записи DNS.

Потеря данных из кэша во время масштабирования?

  • При масштабировании кэша уровня Базовый до другого размера все данные будут утеряны. Во время операции масштабирования кэш будет недоступен.
  • При масштабировании кэша уровня Базовый до уровня Стандартный данные в кэше обычно сохраняются.
  • При масштабировании кэша Standard, Premium, Enterprise или Enterprise Flash до большего размера все данные обычно сохраняются. Если при масштабировании кэша уровня "Стандартный" или "Премиум" до меньшего размера объем данных превышает новый (меньший) размер кэша, данные могут быть утеряны. При потере данных во время масштабирования до меньшего размера ключи вытесняются с помощью политики вытеснения allkeys-lru .

Можно ли использовать все функции уровня "Премиум" после масштабирования?

Нет, некоторые функции можно задать только при создании кэша на уровне "Премиум" и недоступны после масштабирования.

Эти функции нельзя добавить после создания кэша Premium:

  • Внедрение виртуальной сети
  • Добавление избыточности зоны
  • Использование нескольких реплика на основную

Чтобы использовать любую из этих функций, необходимо создать новый экземпляр кэша на уровне "Премиум".

Что происходит с пользовательским параметром databases при масштабировании?

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

  • При масштабировании на ценовую категорию с меньшим databases ограничением, чем текущий уровень:
    • Если вы используете заданное по умолчанию количество databases (16 для всех ценовых категорий), то данные не теряются.
    • Если вы используете настраиваемое количество databases (в пределах ограничений уровня, до которого выполняется масштабирование), значение databases будет сохранено и данные не будут утеряны.
    • Если вы используете настраиваемое количество databases (которое превышает ограничения нового уровня), значение databases будет уменьшено в соответствии с новым уровнем, а все данные в удаленных базах данных будут утеряны.
  • При масштабировании до ценовой категории с равным или более высоким значением databases по сравнению с текущим уровнем значение databases будет сохранено, а данные не будут утеряны.

Хотя кэши Standard, Premium, Enterprise и Enterprise Flash имеют соглашение об уровне обслуживания для доступности, соглашение об уровне обслуживания для потери данных отсутствует.

Будет ли кэш доступен во время масштабирования?

  • Кэши Флэш-памяти уровня "Стандартный", "Премиум", "Корпоративный" и "Корпоративный" остаются доступными во время операции масштабирования. Однако при масштабировании этих кэшей могут возникать скольжения подключений, а также при масштабировании с кэшей "Базовый" до "Стандартный". Сбои подключения обычно длятся недолго, и клиенты Redis, как правило, могут восстановить подключение мгновенно.
  • Для кэшей Enterprise и Enterprise Flash с помощью активной гео-реплика tion масштабирование только подмножества связанных кэшей может привести к проблемам с течением времени в некоторых случаях. По возможности рекомендуется масштабировать все кэши в группе гео-реплика tion.
  • Во время операций масштабирования до другого размера кэши уровня Базовый находятся в автономном режиме. При масштабировании с уровня Базовый до уровня Стандартный кэши уровня "Базовый" остаются доступными, но при этом могут возникнуть непродолжительные сбои подключения. При возникновении сбоев подключения клиенты Redis, как правило, мгновенно восстанавливают подключение.

Имеются ли ограничения на масштабирование, связанные с георепликацией?

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

При настройке активной геоконфигурации реплика невозможно масштабировать кэш. Все кэши в группе гео реплика tion должны иметь одинаковый размер и емкость.

Неподдерживаемые операции

  • Перейти с более высокой ценовой категории на более низкую нельзя.
    • Ценовую категорию кэша Премиум нельзя изменить на категорию Стандартный или Базовый.
    • Ценовую категорию кэша Стандартный нельзя изменить на категорию Базовый.
  • Вы можете выполнить масштабирование кэша с уровня Базовый до уровня Стандартный, но вам не удастся одновременно с этим изменить размер кэша. Если требуется изменить размер, можно позднее выполнить операцию масштабирования до нужного размера.
  • Ценовую категорию кэша Базовый нельзя изменить сразу на уровень Премиум. Сначала выполните масштабирование с категории Базовый на категорию Стандартный, а затем — с категории Стандартный на категорию Премиум.
  • Вы не можете масштабировать кэш Уровня "Премиум" до кэша Enterprise или Enterprise Flash.
  • Вам не удастся выполнить масштабирование с большего размера до размера C0 (250 МБ) .

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

Сколько времени занимает масштабирование?

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

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

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

Как узнать, когда масштабирование завершено?

На портале Azure вы увидите, как выполняется операция масштабирования. После завершения масштабирования состояние кэша изменяется на Работает.

Нужно ли вносить изменения в клиентское приложение, чтобы использовать кластеризацию?

  • Если кластеризация включена, доступна только база данных 0. Если клиентское приложение использует несколько баз данных и пытается выполнить чтение или запись в базе данных, отличной от 0, порождается приведенное ниже исключение: Unhandled Exception: StackExchange.Redis.RedisConnectionException: ProtocolFailure on GET --->StackExchange.Redis.RedisCommandException: Multiple databases are not supported on this server; cannot switch to database: 6

    Дополнительные сведения см. в разделе "Implemented subset" (Реализованное подмножество) статьи Redis Cluster Specification (Спецификация кластера Redis).

  • Если вы используете клиент StackExchange.Redis, необходимо установить версию 1.0.481 или более позднюю. Вы можете подключаться к кэшу с помощью тех же конечных точек, портов и ключей, которые используются для подключения к кэшу с отключенной кластеризацией. Единственное отличие заключается в том, что все операции чтения и записи должны выполняться в базе данных 0.

    Требования других клиентов могут отличаться. Ознакомьтесь с разделом Все ли клиенты Redis поддерживают кластеризацию?

  • Если приложение использует несколько операций с ключом, объединенных в одну команду, все ключи должны быть расположены в одном сегменте. Чтобы найти ключи, расположенные в одном сегменте, см. раздел Как ключи распределены в кластере?

  • Если вы используете поставщик состояний сеансов ASP.NET Redis, вам необходимо установить версию 2.0.1 или более позднюю версию. Ознакомьтесь с разделом Можно ли использовать кластеризацию с поставщиками состояний сеансов и кэширования выходных данных ASP.NET Redis?

Важно!

При использовании уровней FLash enterprise или Enterprise вы можете выбрать режим кластера OSS или корпоративный кластерный режим. Режим кластера OSS совпадает с кластеризация на уровне "Премиум" и соответствует спецификации открытый код кластеризация. Режим корпоративного кластера может быть менее производительным, но использует Redis Enterprise кластеризация который не требует каких-либо изменений клиента для использования. Дополнительные сведения см. в разделе "Кластеризация на предприятии".

Распределение ключей в кластере

В документации Redis по модели распространения ключей: ключевое пространство разделено на 16 384 слотов. Каждый ключ хэшируется и присваивается одному из этих слотов, распределенных между узлами кластера. С помощью хэш-тегов вы можете указать хэшируемую часть ключа, чтобы убедиться в том, что несколько ключей находятся в одном сегменте.

  • Ключи с хэш-тегом. Если любая часть ключа заключена в фигурные скобки — { и }, — для определения хэш-слота ключа хэшируется только эта часть. Например, три ключа — {key}1, {key}2 и {key}3 — будут расположены в одном сегменте, так как хэшируется только часть имени key. Полный список спецификаций для хэш-тегов ключей см. в разделе Keys hash tags (Хэш-теги ключей).
  • Ключи без хэш-тега — для хэширования используется полное имя ключа, что приводит к статистическому равномерному распределению по сегментам кэша.

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

Дополнительные сведения см. в разделах Keys distribution model (Модель распределения ключей), Redis Cluster data sharding (Сегментирование данных в кластере Redis) и Keys hash tags (Хэш-теги ключей).

Пример кода по работе с кластеризацией и поиска ключей в одном сегменте для клиента StackExchange.Redis см. в части clustering.cs примера Hello World.

Каков максимальный размер кэша, который можно создать?

Самый большой размер кэша, который можно использовать, составляет 4,5 ТБ. Этот результат представляет собой кластеризованный кэш F1500 с емкостью 9. Дополнительные сведения см. на странице Цены на Кэш Azure для Redis.

Все ли клиенты Redis поддерживают кластеризацию?

Многие клиентские библиотеки поддерживают кластеризацию Redis, но не все. Проверьте документацию по используемой вами библиотеке и убедитесь, что вы используете библиотеку и версию, которые поддерживают функцию кластеризации. StackExchange.Redis - это одна из библиотек, которая поддерживает кластеризацию в ее новых версиях. Дополнительные сведения о других клиентах см. в разделе Playing with the cluster (Эксперименты с кластером) руководства по кластерам Redis.

Протокол кластеризации Redis требует, чтобы каждый клиент подключался к каждому сегменту напрямую в режиме кластеризации, а также определяет новые ответы на ошибки, такие как «MOVED» на «CROSSSLOTS». При попытке использовать клиентскую библиотеку, которая не поддерживает кластеризацию с кэшем режима кластера, может привести к множеству исключений переадресации MOVED или просто нарушить работу вашего приложения, если вы выполняете запросы с несколькими ключами между слотами.

Примечание.

Если вы используете StackExchange.Redis в качестве клиента, убедитесь, что вы используете последнюю версию StackExchange.Redis 1.0.481 или более поздней, чтобы кластеризация работать правильно. Ознакомьтесь с дополнительными сведениями о проблемах с исключениями MOVE.

Как подключиться к кэшу, если кластеризация включена?

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

Можно ли напрямую подключаться к отдельным сегментам кэша?

Для протокола кластеризации требуется, чтобы клиент установил правильные подключения к сегментам, поэтому клиент должен предоставить вам доступ к общим подключениям. Тем не менее каждый сегмент включает пару, которая включает основной кэш и его реплику и называется экземпляром кэша. Вы можете подключиться к этим экземплярам кэша с помощью служебной программы Redis-CLI в нестабильной ветви репозитория Redis на сайте GitHub. Эта версия реализует базовую поддержку при запуске с параметром -c. Дополнительные сведения см. в разделе Игра с кластером на странице https://redis.io в Руководстве по кластерам Redis .

Необходимо использовать переключатель, чтобы указать правильный -p порт для подключения. Используйте команду CLUSTER NODES, чтобы определить точные порты, используемые для основных и реплика узлов. Используются следующие диапазоны портов:

  • Для кэшей уровня "Премиум" не TLS порты доступны в диапазоне 130XX .
  • Для кэшей уровня "Премиум" с поддержкой TLS порты доступны в диапазоне 150XX
  • Для кэшей Enterprise и Enterprise Flash с помощью OSS кластеризация начальное подключение осуществляется через порт 10000. Подключение для отдельных узлов можно сделать с помощью портов в диапазоне 85XX. Порты 85xx будут изменяться со временем и не должны быть жестко закодированы в приложение.

Можно ли настроить кластеризацию для ранее созданного кэша?

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

Важно!

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

Все кэши уровня Enterprise и Enterprise Flash всегда кластеризованы.

Можно ли настроить кластеризацию для кэша уровней Базовый и Стандартный?

Кластеризация доступна только для кэшей Premium, Enterprise и Enterprise Flash.

Можно ли использовать кластеризацию с поставщиками состояний сеансов и кэширования выходных данных ASP.NET Redis?

  • Поставщик кэша вывода Redis — изменения не требуются.
  • Поставщик состояний сеансов Redis — для кластеризации необходимо использовать RedisSessionStateProvider 2.0.1 или более поздней версии. В противном случае будет порождено исключение, так как это критическое изменение. Дополнительные сведения см. в подробном описании критических изменений версии 2.0.0.

Что делать если при использовании StackExchange.Redis и кластеризации порождаются исключения MOVE?

Если вы применяете StackExchange.Redis и получаете исключения MOVE при кластеризации, убедитесь, что вы используете StackExchange.Redis 1.1.603 или более позднюю версию. Инструкции по настройке приложений .NET для использования StackExchange.Redis см. в разделе Настройка клиентов кэша.

Какова разница между кластеризациям OSS и корпоративным кластеризациям в кэшах уровня Enterprise?

Режим кластера OSS совпадает с кластеризация на уровне "Премиум" и соответствует спецификации открытый код кластеризация. Режим корпоративного кластера может быть менее производительным, но использует Redis Enterprise кластеризация, который не требует каких-либо изменений клиента для использования. Дополнительные сведения см. в разделе "Кластеризация на предприятии".

Сколько сегментов используют кэши уровня Enterprise?

В отличие от кэшей уровня "Базовый", "Стандартный" и "Премиум", кэши Enterprise и Enterprise Flash могут использовать несколько сегментов на одном узле. Дополнительные сведения см. в разделе "Сегментирование" и "Использование ЦП".

Следующие шаги