Заметка
Доступ к этой странице требует авторизации. Вы можете попробовать войти в систему или изменить каталог.
Доступ к этой странице требует авторизации. Вы можете попробовать сменить директорию.
Это важно
Кэш Azure для Redis объявил о графике вывода из эксплуатации для всех SKU. Мы рекомендуем переместить существующие экземпляры кэша для Redis в Azure Managed Redis как можно скорее.
Дополнительные сведения о выходе на пенсию:
Команды повторных попыток
Настройте клиентские подключения для повторных попыток команд с экспоненциальным откатом. Дополнительные сведения см. в рекомендациях по повторным попыткам.
Проверка устойчивости
Проверьте устойчивость системы к разрывам подключения с помощью перезагрузки для имитации исправления. Дополнительные сведения о тестировании производительности см. в разделе "Тестирование производительности".
Параметры TCP для клиентских приложений, размещенных в Linux
Параметры TCP по умолчанию в некоторых версиях Linux могут привести к сбою подключений сервера Redis в течение 13 минут или более. Параметры по умолчанию могут запретить клиентскому приложению обнаруживать закрытые подключения и автоматически восстанавливать их, если подключение не было закрыто корректно.
Сбой повторного обновления подключения может произойти в ситуациях, когда сетевое подключение нарушено или сервер Redis переходит в автономный режим для незапланированного обслуживания.
Рекомендуется использовать следующие параметры TCP:
| Setting | Ценность |
|---|---|
net.ipv4.tcp_retries2 |
5 |
Дополнительные сведения о сценарии см. в разделе Подключение не восстанавливается в течение 15 минут при запуске на Linux. Хотя это обсуждение относится к библиотеке StackExchange.Redis , другие клиентские библиотеки, работающие в Linux, также затронуты. Объяснение по-прежнему полезно, поскольку его можно обобщить на другие библиотеки.
Использование ForceReconnect с StackExchange.Redis
В редких случаях StackExchange.Redis не удается переподключиться после разрыва соединения. В таких случаях перезапуск клиента или создание нового ConnectionMultiplexer исправляет проблему. Рекомендуется использовать единый ConnectionMultiplexer шаблон, позволяя приложениям периодически выполнять повторное подключение. Ознакомьтесь с примером проекта быстрого старта, который лучше всего соответствует фреймворку и платформе, которые использует ваше приложение. Пример этого шаблона кода можно просмотреть в наших кратких руководствах.
Пользователи ConnectionMultiplexer должны обрабатывать любые ObjectDisposedException ошибки, которые могут возникнуть в результате удаления старого.
Вызов ForceReconnectAsync() для RedisConnectionExceptions и RedisSocketExceptions. Вы также можете позвонить ForceReconnectAsync()RedisTimeoutExceptions, но только если вы используете щедрые ReconnectMinInterval и ReconnectErrorThreshold. В противном случае установка новых подключений может привести к каскадному сбою на сервере, испытывающем тайм-аут, поскольку он уже перегружен.
В приложении ASP.NET можно использовать интегрированную реализацию в пакете Microsoft.Extensions.Caching.StackExchangeRedis вместо непосредственного использования пакета StackExchange.Redis . Если вы используете Microsoft.Extensions.Caching.StackExchangeRedis в приложении ASP.NET, а не с помощью StackExchange.Redis напрямую, можно задать UseForceReconnect для свойства значение true:
Microsoft.AspNetCore.Caching.StackExchangeRedis.UseForceReconnect = true
Настройка параметров времени ожидания
Важно учитывать два значения времени ожидания подключения: время ожидания подключения и время ожидания команды.
Время ожидания подключения
Это connect timeout время, когда клиент ожидает установления подключения к серверу Redis. Настройте клиентскую библиотеку для использования тайм-аута в connect timeout пять секунд, что дает системе достаточно времени для подключения даже при высокой нагрузке на ЦП.
Небольшое connection timeout значение не гарантирует, что подключение устанавливается в этом интервале времени. Если что-то пошло не так (высокий уровень ЦП клиента, высокий ЦП сервера и т. д.), то короткое connection timeout значение приводит к сбою подключения. Это поведение часто ухудшает ситуацию. Вместо того, чтобы помочь, более короткие тайм-ауты усугубят проблему, заставляя систему перезапустить процесс повторного подключения, что может привести к подключению -> сбой -> цикл повторных попыток .
Время ожидания команды
Большинство клиентских библиотек имеют другую конфигурацию времени ожидания для command timeouts. Это время, которое клиент ждет ответа от сервера Redis. Хотя мы рекомендуем начальный параметр менее пяти секунд, рекомендуется задать command timeout более высокий или более низкий размер в зависимости от вашего сценария и размеров значений, хранящихся в кэше.
Если command timeout слишком мал, подключение может казаться нестабильным. Однако, если command timeout слишком велик, вашему приложению, возможно, придется долго ждать, чтобы узнать, истечет ли время выполнения команды.
Избегайте пиков подключения клиента
Избегайте создания нескольких подключений одновременно при повторном подключении после потери подключения. Аналогично тому, как короткие сроки ожидания подключения могут привести к более длительным сбоям, при запуске многих попыток повторного подключения одновременно может также увеличить нагрузку сервера и продлить время, необходимое для успешного повторного подключения всех клиентов.
Если вы вновь подключаете многочисленные клиентские экземпляры, рассмотрите возможность поэтапного установления новых подключений, чтобы избежать резкого всплеска числа подключенных клиентов.
Замечание
При использовании клиентской библиотеки StackExchange.Redis задайте abortConnect значение false в строке подключения. Рекомендуется позволить ConnectionMultiplexer осуществлять повторное подключение. Дополнительные сведения см. в рекомендациях StackExchange.Redis.
Избегайте оставшихся подключений
Кэши имеют ограничения на количество клиентских подключений на уровне кэша. Убедитесь, что при восстановлении вашего клиентского приложения он закрывает и удаляет старые подключения.
Уведомление о предварительном обслуживании
Используйте уведомления для получения сведений о предстоящем обслуживании. Дополнительные сведения см. в разделе "Можно ли получать уведомления заранее о плановом обслуживании".
Расписание периода обслуживания
Настройте параметры кэша в соответствии с обслуживанием. Дополнительные сведения о создании периода обслуживания для уменьшения негативных последствий для кэша см. в разделе "Канал обновления" и "Расписание обновлений".
Дополнительные шаблоны проектирования для обеспечения устойчивости
Применение шаблонов проектирования для повышения устойчивости. Дополнительные сведения см. в статье "Как сделать приложение устойчивым".
Время ожидания простоя
Кэш Azure для Redis имеет 10-минутное время ожидания для простоя соединений. 10-минутный тайм-аут позволяет серверу автоматически очищать утечки соединений или соединения, оставленные клиентским приложением. Большинство клиентских библиотек Redis имеют встроенную возможность периодически отправлять heartbeat или keepalive команды, чтобы предотвратить закрытие подключений, даже если нет запросов от клиентского приложения.
Если есть риск простоя подключений в течение 10 минут, настройте keepalive интервал в значение менее 10 минут. Если приложение использует клиентскую библиотеку, которая не поддерживает собственные keepalive функции, ее можно реализовать в приложении, периодически отправляя PING команду.