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 restaurarlas 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.

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

Si usa la biblioteca cliente 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 obtener más información sobre cómo crear una ventana de mantenimiento para reducir los efectos negativos en la caché, vea 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

Actualmente, Azure Cache for Redis tiene un tiempo de espera de inactividad de 10 minutos para las conexiones, por lo que la configuración de tiempo de espera de inactividad en la aplicación cliente debe ser inferior a 10 minutos. Las bibliotecas cliente más comunes tienen una configuración que permite que las bibliotecas cliente envíe comandos PING de Redis a un servidor de Redis de manera automática y periódica. Sin embargo, al usar bibliotecas cliente sin este tipo de configuración, las propias aplicaciones cliente son responsables de mantener activa la conexión.

Pasos siguientes