Resistencia de la conexión
Reintento de comandos
Configure las conexiones cliente para el reintento de comandos con retroceso exponencial. Para obtener más información, vea Instrucciones de reintento.
Prueba de la resistencia
Pruebe la resistencia del sistema a las interrupciones de conexión mediante un reinicio para simular una aplicación de revisiones. Para obtener más información sobre las pruebas de rendimiento, vea Pruebas de rendimiento.
Configuración de TCP para aplicaciones cliente hospedadas en Linux
La configuración de TCP predeterminada en algunas versiones de Linux puede provocar un error en las conexiones de servidor de Redis durante 13 minutos o más. La configuración predeterminada puede impedir que la aplicación cliente detecte conexiones cerradas y las restaure automáticamente si la conexión no se cerró correctamente.
El error al restablecer una conexión puede producirse en situaciones en las que se interrumpe la conexión de red o el servidor de Redis se queda sin conexión para el mantenimiento no planeado.
Se recomienda esta configuración de TCP:
| Configuración | Valor |
|---|---|
net.ipv4.tcp_retries2 |
5 |
Para obtener más información sobre el escenario, consulte La conexión no se establece de nuevo durante 15 minutos cuando se ejecuta en Linux. Aunque este artículo trata sobre la biblioteca StackExchange.Redis, también se ven afectadas otras bibliotecas cliente que se ejecutan en Linux. La explicación sigue siendo útil y se puede generalizar a otras bibliotecas.
Uso de ForceReconnect con StackExchange.Redis
En raras ocasiones, StackExchange.Redis no se puede volver a conectar después de que se anule una conexión. En estos casos, reiniciar el cliente o crear un nuevo objeto ConnectionMultiplexer corrige el problema. Se recomienda usar un patrón de singleton ConnectionMultiplexer al tiempo que se permite que las aplicaciones fuercen una reconexión periódicamente. Eche un vistazo al proyecto de ejemplo de inicio rápido que mejor se adapte al marco y la plataforma que usa la aplicación. Puede ver un ejemplo de este patrón de código en nuestros inicios rápidos.
Los usuarios del objeto ConnectionMultiplexer deben controlar los errores de ObjectDisposedException que puedan producirse como resultado de eliminar el anterior.
Llame a ForceReconnectAsync() para RedisConnectionExceptions y RedisSocketExceptions. También puede llamar a ForceReconnectAsync() para RedisTimeoutExceptions, pero solo si usa valores generosos de ReconnectMinInterval y ReconnectErrorThreshold. De lo contrario, el establecimiento de nuevas conexiones puede provocar un error en cascada en un servidor que está agotando el tiempo de espera porque ya está sobrecargado.
En una aplicación ASP.NET, puede usar la implementación integrada en el paquete microsoft.Extensions.Caching.StackExchangeRedis en lugar de usar directamente el paquete StackExchange.Redis. Si usa microsoft.Extensions.Caching.StackExchangeRedis en una aplicación ASP.NET en lugar de usar StackExchange.Redis directamente, puede establecer la propiedad UseForceReconnect en true:
Microsoft.AspNetCore.Caching.StackExchangeRedis.UseForceReconnect = true
Configuración de tiempos de espera adecuados
Dos valores de tiempo de espera que es importante tener en cuenta para la resistencia de la conexión: tiempo de espera de conexión y tiempo de espera del comando.
Tiempo de espera de conexión
El connect timeout es el tiempo que el cliente espera para establecer una conexión con el servidor de Redis. Configure la biblioteca cliente para usar un valor connect timeout de cinco segundos, lo que da al sistema tiempo suficiente para conectarse incluso en condiciones mucho uso de la CPU.
Un valor de connection timeout bajo no garantiza que se establezca una conexión en ese plazo de tiempo. Si algo va mal (CPU de cliente alta, CPU de servidor alta, etc.), un valor connection timeout corto provoca un error del intento de conexión. Este comportamiento suele empeorar una situación que ya es mala de por si. En lugar de mejorar el problema, los tiempos de espera más cortos lo agravan, ya que obligan al sistema a reiniciar el proceso de conexión, lo que puede llevar a un bucle conectar -> error -> reintentar.
Tiempo de espera del comando
La mayoría de las bibliotecas cliente tienen otra configuración de tiempo de espera para los command timeouts, que es el tiempo que el cliente espera una respuesta del servidor Redis. Aunque se recomienda una configuración inicial de menos de cinco segundos, considere la posibilidad de establecer el valor command timeout más alto o más bajo en función del escenario y los tamaños de los valores almacenados en la memoria caché.
Si el command timeout es demasiado bajo, la conexión puede parecer inestable. Pero si el valor command timeout es demasiado elevado, es posible que la aplicación tenga que esperar mucho tiempo para averiguar si el comando va a agotar el tiempo de espera o no.
Evitar picos de conexión cliente
Evite crear muchas conexiones al mismo tiempo al volver a conectarse después de una pérdida de conexión. Al igual que los tiempos de espera de conexión cortos pueden dar lugar a interrupciones más largas, el inicio de muchos intentos de reconexión al mismo tiempo también puede aumentar la carga del servidor y extender el tiempo que tardan todos los clientes en volver a conectarse correctamente.
Si va a volver a conectar muchas instancias de cliente, considere la posibilidad de escalonar las nuevas conexiones para evitar un pico fuerte en el número de clientes conectados.
Nota:
Cuando usa la biblioteca cliente de StackExchange.Redis, establezca abortConnect en false en la cadena de conexión. Se recomienda permitir que ConnectionMultiplexer controle la reconexión. Para obtener más información, vea Procedimientos recomendados de StackExchange.Redis.
Evitar conexiones sobrantes
Las memorias caché tienen límites en cuanto al número de conexiones cliente por nivel de caché. Asegúrese de que cuando la aplicación cliente vuelva a crear las conexiones, cierre y elimine las conexiones antiguas.
Notificación de mantenimiento avanzado
Use notificaciones para obtener información sobre el próximo mantenimiento. Para obtener más información, vea ¿Se puede recibir una notificación previa a un mantenimiento planeado?.
Programación de la ventana de mantenimiento
Ajuste la configuración de la caché para dar cabida al mantenimiento. Para más información sobre la creación de una ventana de mantenimiento para reducir cualquier efecto negativo en su caché, consulte Canal de actualización y programación de actualizaciones.
Más patrones de diseño para la resistencia
Aplique patrones de diseño para la resistencia. Para obtener más información, vea Cómo hacer que mi aplicación sea resistente.
Tiempo de espera inactividad
Azure Cache for Redis tiene un tiempo de espera de 10 minutos para las conexiones inactivas. El tiempo de espera de 10 minutos permite al servidor limpiar automáticamente las conexiones filtradas o las huérfanas a causa de una aplicación cliente. La mayoría de las bibliotecas cliente de Redis tienen una capacidad integrada para enviar comandos heartbeat o keepalive periódicamente a fin de evitar que las conexiones se cierren incluso si no hay solicitudes de la aplicación cliente.
Si hay algún riesgo de que las conexiones permanezcan inactivas durante 10 minutos, configure el intervalo keepalive en un valor inferior a 10 minutos. Si la aplicación usa una biblioteca cliente que no tiene compatibilidad nativa con la función keepalive, puede implementarla en la aplicación enviando un comando PING con frecuencia.