Разработка с использованием Azure Managed Redis

  • Применяется к: ✅ Azure Managed Redis

В этой статье мы обсудим, как разрабатывать код для Azure Managed Redis.

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

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

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

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

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

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

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

|-------- 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, потребляют очень много ресурсов, поэтому следует их избегать. Некоторые соображения относительно длительно выполняемых команд см. в разделе о длительных командах.

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

Azure Managed Redis предлагает уровни, оптимизированные для памяти, сбалансированные, оптимизированные для вычислений и оптимизированные для флэш-памяти. Дополнительные сведения о том, как выбрать уровень, см. в разделе "Как масштабировать". Рекомендуется выполнить тестирование производительности, чтобы выбрать правильный уровень и проверить настройки соединения. Дополнительные сведения см. в статье Тестирование производительности.

Выбор подходящего режима доступности

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

Клиент в том же регионе, что и экземпляр Redis

Найдите инстанцию Redis и приложение в одном и том же регионе. Подключение к Redis в другом регионе может значительно увеличить задержку и снизить надежность.

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

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

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

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

Azure Managed Redis по умолчанию использует TLS-зашифрованные соединения. В настоящее время поддерживаются tls версии 1.2 и 1.3. Если клиентская библиотека или средство не поддерживает TLS, возможно включение незашифрованных подключений.

Мониторинг использования памяти, метрик использования ЦП, подключений клиентов и пропускной способности сети

При использовании экземпляра Azure Managed Redis в рабочей среде рекомендуется задать оповещения для метрик Процент используется памяти, CPU, Подключенные клиенты. Если эти метрики последовательно превышают 75%, рассмотрите возможность масштабирования экземпляра до большей памяти или более высокой пропускной способности. Дополнительные сведения см. в статье о масштабировании. Дополнительные сведения о том, как сообщается память и как спланировать емкость, см. в разделе "Управление памятью".

Рассмотрите возможность включения сохраняемости данных или резервного копирования данных

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

Функция устойчивости данных предназначена для автоматического предоставления точки быстрого восстановления данных в случае сбоя кэша. Быстрое восстановление возможно путем хранения RDB или AOF-файла на управляемом диске, подключенном к экземпляру кэша. Файлы постоянного хранения на диске недоступны для пользователей и не могут использоваться ни одним другим экземпляром AMR.

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

Руководство для конкретной клиентской библиотеки

Для получения дополнительной информации см. клиентские библиотеки Azure Managed Redis

Связанный контент

  • Last updated on