Nota:
El acceso a esta página requiere autorización. Puede intentar iniciar sesión o cambiar directorios.
El acceso a esta página requiere autorización. Puede intentar cambiar los directorios.
Importante
Azure Cache for Redis anunció su cronograma de retiro para todos los SKU. Se recomienda mover las instancias existentes de Azure Cache for Redis a Azure Managed Redis tan pronto como pueda.
Para obtener más información sobre la retirada:
Comandos de reintento
Configure las conexiones cliente para el reintento de comandos con retroceso exponencial. Para obtener más información, consulte las directrices de reintento.
Prueba de la resistencia
Pruebe la resistencia del sistema a las interrupciones de conexión mediante un reinicio para simular una actualización. Para obtener más información sobre cómo probar el rendimiento, consulte 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 de 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 | Importancia |
|---|---|
net.ipv4.tcp_retries2 |
5 |
Para obtener más información sobre el escenario, consulte Conexión no se restablece durante 15 minutos al ejecutarse en Linux. Aunque esta explicación se refiere a la biblioteca StackExchange.Redis , también se ven afectadas otras bibliotecas cliente que se ejecutan en Linux. La explicación sigue siendo útil y puede generalizarse en otras bibliotecas.
Uso de ForceReconnect con StackExchange.Redis
En raras ocasiones, StackExchange.Redis no se puede volver a conectar después de quitar una conexión. En estos casos, reiniciar el cliente o crear una nueva ConnectionMultiplexer soluciona el problema. Se recomienda usar un patrón singleton ConnectionMultiplexer a la vez que se permite a las aplicaciones forzar una reconexión periódicamente. Eche un vistazo al proyecto de ejemplo de inicio rápido que mejor coincida con el 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, establecer nuevas conexiones puede provocar un fallo en cascada en un servidor cuyo tiempo de respuesta se esté agotando 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 de ASP.NET en lugar de usar StackExchange.Redis directamente, puede establecer la UseForceReconnect propiedad en true:
Microsoft.AspNetCore.Caching.StackExchangeRedis.UseForceReconnect = true
Configurar los tiempos de espera adecuados
Dos valores de tiempo de espera son importantes tener en cuenta en la resistencia de conexión: tiempo de espera de conexión y tiempo de espera de comandos.
Tiempo de espera de conexión
connect timeout es el momento en que el cliente espera a establecer una conexión con el servidor de Redis. Configure la biblioteca cliente para usar un connect timeout valor de cinco segundos, lo que proporciona al sistema tiempo suficiente para conectarse incluso en condiciones de CPU más altas.
Un valor pequeño connection timeout no garantiza que se establezca una conexión en ese período de tiempo. Si algo va mal (CPU de cliente alta, CPU de servidor alta, etc.), un valor corto connection timeout hace que se produzca un error en el intento de conexión. Este comportamiento suele empeorar la situación. En lugar de ayudar, los tiempos de espera más cortos agravan el problema al obligar al sistema a reiniciar el proceso de intentar volver a conectarse, lo que puede provocar un bucle de conectar -> fallar -> reintentar.
Tiempo de espera del comando
La mayoría de las bibliotecas cliente tienen otra configuración de tiempo de espera para command timeouts, que es el momento en que el cliente espera una respuesta del servidor de Redis. Aunque se recomienda una configuración inicial de menos de cinco segundos, considere la posibilidad de establecer el command timeout valor superior o inferior en función de su escenario y los tamaños de los valores almacenados en la memoria caché.
Si es command timeout demasiado pequeño, la conexión puede parecer inestable. Sin embargo, si es command timeout demasiado grande, 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 de cliente
Evite crear muchas conexiones al mismo tiempo al volver a conectarse después de una pérdida de conexión. De forma similar a la forma en que los tiempos de espera de conexión cortos pueden provocar interrupciones más largas, iniciar muchos intentos de reconexión al mismo tiempo también puede aumentar la carga del servidor y ampliar cuánto tiempo 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 elevado en el número de clientes conectados.
Nota:
Cuando use la biblioteca cliente StackExchange.Redis, establezca abortConnect en false dentro de la cadena de conexión. Se recomienda dejar que el ConnectionMultiplexer maneje la reconexión. Para obtener más información, consulte Procedimientos recomendados de StackExchange.Redis.
Evitar conexiones sobrantes
Las memorias caché tienen límites en el número de conexiones de 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 anticipada
Use notificaciones para obtener información sobre el próximo mantenimiento. Para obtener más información, consulte ¿Puedo recibir una notificación con antelación de un mantenimiento planeado?
Programar ventana de mantenimiento
Ajuste la configuración de la memoria 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 de la memoria caché, consulte Actualización del canal y Programación de actualizaciones.
Más patrones de diseño para la resistencia
Aplicar patrones de diseño para la resistencia. Para obtener más información, consulte Cómo puedo 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 funcionalidad integrada para enviar heartbeatkeepalive o comandos periódicamente para 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 estén inactivas durante 10 minutos, configure el keepalive intervalo en un valor inferior a 10 minutos. Si su aplicación utiliza una biblioteca cliente que no tiene compatibilidad nativa con la funcionalidad keepalive, puede implementarla en su aplicación enviando un comando PING periódicamente.