Разработка

Статья
04/18/2024

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

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

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

Кэш 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-адреса мы рекомендуем использовать имя узла. Ниже приведены рекомендуемые формы имени узла для различных уровней:

Уровень	Форма
"Базовый", "Стандартный" и "Премиум"	`<cachename>.redis.cache.windows.net`
Enterprise, Enterprise Flash	`<DNS name>.<Azure region>.redisenterprise.cache.azure.net.`

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

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

Конкретные рекомендации по уровням Enterprise

Так как уровни Enterprise и Enterprise Flash основаны на Redis Enterprise, а не с открытым исходным кодом Redis, существуют некоторые различия в рекомендациях по разработке. Дополнительные сведения см. в рекомендациях по уровням Enterprise и Enterprise Flash.

Использование шифрования 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. Он не включает суверенные (например, Китай) или правительственные облака.

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

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

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

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

Тип ЦС	Текущие	После отката (12 октября, 2020)	Действие
Корневой	Отпечаток: d4de20d05e66fc53fe1a50882c78db2852cae474 Срок действия: понедельник, 12 мая 2025 г., 4:59:00 PM Имя субъекта: CN = Baltimore CyberTrust Root OU = CyberTrust O = Baltimore C = IE	Без изменений	нет
Промежуточный	Отпечатки: CN = Microsoft IT TLS CA 1 Отпечаток: 417e225037fbfaa4f95761d5ae729e1aea7e3a42 CN = Microsoft IT TLS CA 2 Отпечаток: 54d9d20239080c32316ed9ff980a48988f4adf2d CN = Microsoft IT TLS CA 4 Отпечаток: 8a38755d0996823fe8fa3116a277ce446eac4e99 CN = Microsoft IT TLS CA 5 Отпечаток: Ad898ac73df333eb60ac1f5fc6c4b2219ddb79b7 Срок действия: пятница, 20 мая 2024 г., 5:52:38 AM Имя субъекта: OU — Microsoft IT O = Microsoft Corporation L = Redmond S = Washington C = US	Отпечатки: CN = Microsoft RSA TLS CA 01 Отпечаток: 703d7a8f0ebf55aaa59f98eaf4a206004eb2516a CN = Microsoft RSA TLS CA 02 Отпечаток: b0c2d2d13cdd56cdaa6ab6e2c04440be4a429c75 Срок действия: вторник, 8 октября 2024 г., 12:00:00 AM; Имя субъекта: O = Microsoft Corporation C = US	Обязательное поле

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

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

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

Сертификат	Отпечаток
Baltimore Root CA	d4de20d05e66fc53fe1a50882c78db2852cae474
Microsoft RSA Root Certificate Authority 2017	73a5e64a3bff8316ff0edccc618a906e4eae4d74
Digicert Global Root G2	df3c24f9bfd666761b268073fe06d1cc8d4f82a4

Совет

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

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

Общее имя ЦС	Отпечаток
Microsoft RSA TLS CA 01	703d7a8f0ebf55aaa59f98eaf4a206004eb2516a
Microsoft RSA TLS CA 02	b0c2d2d13cdd56cdaa6ab6e2c04440be4a429c75
Microsoft Azure TLS, выдающий ЦС 01	2f2877c5d778c31e0f29c7e371df5471bd673173
Microsoft Azure TLS, выдающий ЦС 02	e7eea674ca718e3befd90858e09f8372ad0ae2aa
Microsoft Azure TLS, выдающий ЦС 05	6c3af02e7f269aa73afd0eff2a88a4a1f04ed1e5
Microsoft Azure TLS, выдающий ЦС 06	30e01761ab97e59a06b41ef20af6f2de7ef4f7b0

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

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

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