Разработка

Устойчивость соединений и загруженность сервера

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

Возможно, следует использовать дополнительные ключи и меньшие значения

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

Большой размер запроса или ответа

Из-за большого размера запроса или ответа может истекать время ожидания. Для примера предположим, что время ожидания на клиентском компьютере установлено равным 1 секунде. Приложение одновременно запрашивает два ключа (например, А и Б) в одном физическом сетевом подключении. Большинство клиентов поддерживают конвейерную обработку запросов , где оба запроса "A" и "B" отправляются один после другого, не ожидая их ответов. Сервер отправляет ответы в том же порядке. Если ответ на запрос "А" достаточно велик, его передача может занять большую часть времени ожидания последующих запросов.

В следующем примере запросы "A" и "B" отправляются на сервер быстро. Сервер так же быстро начинает отправлять ответы "A" и "B". В связи с длительным временем передачи данных перед отправкой ответа "B" приходится дожидаться, пока будет передан ответ "A", и время ожидания ответа "B" истекает, хотя сервер ответил быстро.

|-------- 1 Second Timeout (A)----------|
|-Request A-|
     |-------- 1 Second Timeout (B) ----------|
     |-Request B-|
            |- Read Response A --------|
                                       |- Read Response B-| (**TIMEOUT**)

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

Проблема ответов большого размера решается различными способами, например:

• Оптимизировать приложение в расчете на множество небольших значений вместо нескольких больших.
  • Поэтому рекомендуется разбить данные на небольшие связанные части.
  • Подробнее о том, почему рекомендуется использовать меньшие значения, см. в обсуждении вопроса на форуме "What is the ideal value size range for redis? Is 100 KB too large?" (Каков идеальный диапазон размеров значения для Redis? 100 КБ — это не слишком много?).
• Увеличьте размер виртуальной машины, чтобы получить более высокую пропускную способность.
  • Больше пропускной способности на виртуальной машине клиента или сервера может снизить время передачи данных для более крупных ответов.
  • Сравните текущее использование сети в обеих виртуальных машинах с ограничениями, установленными для виртуальных машин этого размера. Больше пропускной способности только на сервере или только на клиенте может быть недостаточно.
• Увеличить число объектов подключения, используемых приложением.
  • Используйте метод циклического перебора, чтобы запросы совершались через разные объекты подключения.

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

Если вы планируете использовать кластеризацию Redis, сначала прочтите Рекомендации по кластеризации Redis с использованием ключей.

Использование конвейера

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

Отказ от дорогостоящих операций

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

Выбор соответствующего уровня

Используйте уровни Standard, Premium, Enterprise или Enterprise Flash для производственных систем. Не используйте уровень "Базовый" в рабочей среде. Уровень "Базовый" — это система с одним узлом без репликации данных, которая не регулируется соглашением об уровне обслуживания. Кроме того, используйте по крайней мере кэш C1. Кэши C0 предназначены только для простых сценариев разработки/тестирования, поскольку:

• они совместно используют ядро ЦП;
• используют меньший объем памяти;
• предрасположены к проблемам "шумного соседа".

Рекомендуется выполнить тестирование производительности, чтобы выбрать правильный уровень и проверить настройки соединения. Дополнительные сведения см. в статье Тестирование производительности.

Клиент располагается в том же регионе, что и кэш

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

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

Используйте имя узла вместо общедоступного IP-адреса.

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

Выбор подходящей версии Redis

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

Использование шифрования TLS

По умолчанию Кэш Azure для Redis требует шифрования по протоколу TLS. В настоящее время поддерживаются версии TLS 1.0, 1.1 и 1.2. Однако протоколы TLS 1.0 и 1.1 скоро перестанут использоваться в отрасли, поэтому по возможности используйте TLS 1.2.

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

Изменение сертификата TLS Azure

Майкрософт обновляет службы Azure для использования сертификатов сервера TLS из другого набора центров сертификации (ЦС). Это изменение вводится поэтапно с 13 августа 2020 г. по 26 октября 2020 г. (ориентировочно). Разработчики Azure вносят это изменение, потому что текущие сертификаты ЦС не соответствуют одному из базовых требований форума по центрам сертификации и браузерам. О проблеме было сообщено 1 июля 2020 г., и она относится к нескольким популярным поставщикам инфраструктуры открытого ключа (PKI) по всему миру. Большинство сертификатов TLS, используемых сегодня службами Azure, поступают из PKI Baltimore CyberTrust Root. Служба Кэш Azure для Redis продолжает быть привязана к Корню Балтимора CyberTrust. Однако его сертификаты сервера TLS будут выдаваться новыми промежуточными центрами сертификации (ICA) начиная с 12 октября 2020 года.

Повлияет ли это изменение на работу?

Большинство Кэш Azure для Redis клиентов не затрагиваются изменениями. Приложение может быть затронуто, если оно явно указывает список допустимых сертификатов, практика, известная как закрепление сертификатов. Если он прикреплен к промежуточному или конечному сертификату, а не к Baltimore CyberTrust Root, вы должны немедленно предпринять действия, чтобы изменить конфигурацию сертификата.

Кэш Azure для Redis не поддерживает Срезание OCSP.

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

Что нужно сделать?

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

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

Чтобы продолжить закрепление промежуточных сертификатов, добавьте приведенные ниже ЦС в список закрепленных промежуточных сертификатов (сюда добавлены несколько дополнительных ЦС, чтобы минимизировать будущие изменения):

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

Особые рекомендации для клиентских библиотек

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

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

• Тестирование производительности
• Отработка отказа и исправление в службе "Кэш Azure для Redis"