Устойчивость подключения
Повторная попытка выполнения команды
Настройте клиентские подключения, чтобы повторить попытку выполнения команд с экспоненциальным увеличением задержки. Дополнительные сведения см. в руководстве по обработке повторных попыток.
Проверка устойчивости
Проверьте устойчивость системы к разрывам подключения, имитируя процесс исправления с помощью перезагрузки. Дополнительные сведения о тестировании производительности см. в статье Тестирование производительности.
Параметры TCP для клиентских приложений на базе Linux
Параметры TCP по умолчанию в некоторых версиях Linux могут привести к сбою подключений к серверу Redis в течение 13 минут или более. Параметры по умолчанию могут запретить клиентскому приложению обнаруживать закрытые подключения и автоматически восстанавливать их, если подключение не было закрыто корректно.
Сбой повторного обновления подключения может произойти в ситуациях, когда сетевое подключение нарушено или сервер Redis переходит в автономный режим для незапланированного обслуживания.
Рекомендуем следующие параметры TCP:
| Параметр | Значение |
|---|---|
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 команду.