Разработка с помощью Управляемого Redis (предварительная версия)
Устойчивость соединений и загруженность сервера
При разработке клиентских приложений обязательно учитывайте соответствующие рекомендации для обеспечения устойчивости соединений и управления загруженностью сервера.
Возможно, следует использовать дополнительные ключи и меньшие значения
Управляемый Redis (предварительная версия) Azure лучше всего работает с меньшими значениями. Чтобы распределить данные по нескольким ключам, рассмотрите возможность деления больших блоков данных на меньшие блоки. Дополнительные сведения об идеальном размере значения см. в этой статье.
Большой размер запроса или ответа
Из-за большого размера запроса или ответа может истекать время ожидания. Для примера предположим, что время ожидания на клиентском компьютере установлено равным 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, такие как команда KEYS, потребляют очень много ресурсов, поэтому следует их избегать. Некоторые соображения относительно длительно выполняемых команд см. в разделе о длительных командах.
Выбор соответствующего уровня
Управляемый Redis Azure предлагает оптимизированные для памяти уровни, балансированные, оптимизированные для вычислений и флэш-памяти. Дополнительные сведения о выборе уровня см. здесь. Рекомендуется выполнить тестирование производительности, чтобы выбрать правильный уровень и проверить настройки соединения. Дополнительные сведения см. в статье Тестирование производительности.
Выбор подходящего режима доступности
Управляемый Redis Azure предлагает возможность включения или отключения конфигурации высокой доступности. Если режим высокой доступности отключен, данные, которые экземпляр AMR не будет реплицировать, поэтому экземпляр Redis будет недоступен во время обслуживания. Все данные в экземпляре AMR также будут потеряны в случае планового или незапланированного обслуживания. Мы рекомендуем отключить высокий уровень доступности только для рабочих нагрузок разработки или тестирования. Производительность экземпляров Redis с высоким уровнем доступности также может быть ниже из-за отсутствия репликации данных, что является критически важным распределением нагрузки между основными и репликами сегментов данных.
Клиент в том же регионе, что и экземпляр Redis
Найдите экземпляр Redis и приложение в том же регионе. Подключение к Redis в другом регионе может значительно увеличить задержку и снизить надежность.
Хотя вы можете подключиться извне Azure, это не рекомендуется, особенно при использовании Redis для ускорения производительности приложения или базы данных. Если вы используете сервер Redis как только хранилище ключей и значений, задержка может не быть основной проблемой.
Используйте имя узла вместо общедоступного IP-адреса.
Общедоступный IP-адрес, назначенный экземпляру AMR, может измениться в результате операции масштабирования или улучшения серверной части. Вместо явного общедоступного IP-адреса мы рекомендуем использовать имя узла.
Использование шифрования TLS
Для Управляемого Redis azure требуется шифрование TLS по умолчанию. В настоящее время поддерживаются tls версии 1.2 и 1.3. Если клиентская библиотека или средство не поддерживает TLS, возможно включение незашифрованных подключений.
Мониторинг использования памяти, метрик использования ЦП, подключений клиентов и пропускной способности сети
При использовании управляемого экземпляра Redis в рабочей среде рекомендуется задать оповещения для метрик "Процент используемой памяти", "ЦП", "Подключенные клиенты". Если эти метрики последовательно превышают 75%, рассмотрите возможность масштабирования экземпляра до большей памяти или более высокой пропускной способности. Дополнительные сведения см . в статье о масштабировании .
Рассмотрите возможность включения сохраняемости данных или резервного копирования данных
Redis предназначен для временных данных по умолчанию, что означает, что в редких случаях данные могут быть потеряны из-за различных обстоятельств, таких как обслуживание или сбои. Если приложение учитывает потерю данных, рекомендуется включить сохраняемость данных или периодическое резервное копирование данных с помощью операции экспорта данных.
Функция сохраняемости данных предназначена для автоматического предоставления точки быстрого восстановления данных при переходе кэша. Быстрое восстановление возможно путем хранения RDB или AOF-файла на управляемом диске, подключенном к экземпляру кэша. Файлы сохраняемости на диске недоступны для пользователей или не могут использоваться любым другим экземпляром AMR.
Многие клиенты хотят использовать сохраняемость для периодического резервного копирования данных в кэше. Мы не рекомендуем использовать сохраняемость данных таким образом. Вместо этого используйте функцию импорта и экспорта . Вы можете экспортировать копии данных в формате RDB непосредственно в выбранную учетную запись хранения и активировать экспорт данных как можно чаще. Затем экспортированные данные можно импортировать в любой экземпляр Redis. Экспорт можно активировать на портале или с помощью средств КОМАНДНОй строки, PowerShell или ПАКЕТА SDK.
Особые рекомендации для клиентских библиотек
Дополнительные сведения см . в клиентских библиотеках Azure Managed Redis