Бөлісу құралы:

Масштабирование экземпляра Кэша 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.
  • Внутренние проверки Защитника
    • В кэшах C0 и C1 уровня "Стандартный", в то время как внутренняя проверка Defender выполняется на виртуальных машинах, может возникнуть короткий пик нагрузки на сервер, не вызванный увеличением запросов кэша. Вы видите более высокую задержку для запросов, пока внутренние проверки Защитника выполняются на этих уровнях несколько раз в день. Кэши на уровнях C0 и C1 имеют только один ядро для многозадачных операций, разделяя работу обслуживания внутренних запросов защитника и запросов Redis. Эффект можно уменьшить, масштабируя до более высокого уровня, используя несколько ядер ЦП, например C2.
    • Увеличение размера кэша на более высоких уровнях помогает устранить проблемы с задержкой. Кроме того, на уровне C2 поддерживается до 2000 клиентских подключений.

Дополнительные сведения о том, как определить оптимальную ценовую категорию кэша, см. в разделе Выбор подходящего уровня и статье Часто задаваемые вопросы по планированию Кэша 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 и выберите "Масштаб" в меню "Ресурс".

    Снимок экрана: масштабирование в меню ресурсов.

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

    Снимок экрана: уровни Кэш Azure для Redis.

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

    Снимок экрана: уведомление о масштабировании.

  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 и выберите "Масштаб" в меню "Ресурс".

    Снимок экрана: масштабирование, выбранное в меню

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

    Внимание

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

    Снимок экрана: уровни Enterprise в рабочей области.

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

    Внимание

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

    Снимок экрана: емкость в рабочей области красный прямоугольник вокруг него.

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

    Снимок экрана: уведомление о масштабировании кэша Enterprise.

  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 с помощью активной георепликации масштабирование только подмножества связанных кэшей может привести к проблемам в некоторых случаях. По возможности рекомендуется масштабировать все кэши в группе георепликации.
  • Во время операций масштабирования до другого размера кэши уровня Базовый находятся в автономном режиме. При масштабировании с уровня Базовый до уровня Стандартный кэши уровня "Базовый" остаются доступными, но при этом могут возникнуть непродолжительные сбои подключения. При возникновении сбоев подключения клиенты Redis, как правило, мгновенно восстанавливают подключение.

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

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

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

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

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

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

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

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

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

Масштабирование кэша является нетривиальным действием и может занять много времени.

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

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

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

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

  • Если кластеризация включена, доступна только база данных 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 na 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 можно использовать несколько сегментов на одном узле. Дополнительные сведения см. в разделе "Сегментирование" и "Использование ЦП".

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