Примечание.
Для доступа к этой странице требуется авторизация. Вы можете попробовать войти или изменить каталоги.
Для доступа к этой странице требуется авторизация. Вы можете попробовать изменить каталоги.
В этой статье мы обсудим, как обеспечить устойчивость подключений к кэшу.
Повторная попытка выполнения команды
Настройте клиентские подключения для повторной попытки выполнения команд с экспоненциальной задержкой между попытками. Дополнительные сведения см. в руководстве по обработке повторных попыток.
Параметры 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.
Избегайте остаточных подключений
Кэши имеют ограничения на количество клиентских подключений на каждом уровне кэша. Убедитесь, что когда клиентское приложение воссоздает подключения, оно закрывает и удаляет старые соединения.
Другие конструктивные шаблоны для обеспечения устойчивости
Для обеспечения устойчивости можно применять конструктивные шаблоны. Дополнительные сведения см. в разделе Как сделать приложение отказоустойчивым.
Таймаут бездействия
Управляемый Redis в Azure имеет 10-минутное время ожидания для неактивных подключений. Время ожидания в 10 минут позволяет серверу автоматически очищать утечки соединений или соединения, оставшиеся без привязки после выполнения клиентского приложения. Большинство клиентских библиотек Redis имеют встроенную возможность периодически отправлять heartbeat или keepalive команды, чтобы предотвратить закрытие подключений, даже если нет запросов от клиентского приложения.
Если есть риск простоя подключений в течение 10 минут, настройте keepalive интервал в значение менее 10 минут. Если приложение использует клиентскую библиотеку, которая не поддерживает собственные keepalive функции, ее можно реализовать в приложении, периодически отправляя PING команду.