Redis no se cuelga por la red: es un comando lento en su hilo único

Redis ejecuta los comandos en un solo hilo. Es una decisión de diseño, no un descuido: elimina la sobrecarga de bloqueos y hace que la latencia sea predecible. El problema es que no hay ningún otro hilo que absorba una operación cara, y mientras esa operación corre es lo único que ocurre en la instancia. Todo lo demás se queda esperando detrás.

Desde fuera el síntoma es idéntico a una partición de red o a una pausa larga del recolector de basura. Por eso se diagnostica mal tantas veces. La instancia deja de responder, los clientes acumulan timeouts y uno empieza a mirar switches, MTU y contenedores ruidosos en el mismo host.

El comando, no la infraestructura

Los sospechosos habituales son operaciones que recorren el keyspace entero, ordenaciones costosas o un SMEMBERS sobre un conjunto enorme. Ninguna es un fallo: son comandos legítimos lanzados contra estructuras grandes. El detalle está en que ocupan el único hilo disponible durante todo lo que tardan, y los demás clientes pagan la espera.

La comprobación que ahorra los veinte minutos es el SLOWLOG. Antes de tocar la red, antes de mirar métricas del contenedor, se consulta el registro de comandos lentos. Si en la ventana en la que la instancia parecía colgada aparece un comando concreto con una duración que cubre ese intervalo, ya está: no era la red, ni el GC, ni el vecino. Era ese comando, y todo lo demás era cola acumulada.

Conviene interiorizarlo una vez en lugar de reconstruir el diagnóstico cada vez. El modelo de hilo único es el que da a Redis su latencia predecible, y es también el que hace que un solo comando mal pensado tumbe el servicio entero visto desde el cliente.

La consecuencia práctica es dónde se busca el arreglo. No está en la capa de red ni en el tamaño del contenedor, sino en qué comandos lanzan las aplicaciones y sobre qué estructuras. El SLOWLOG debería ser la primera consulta de la rutina, no la última tras veinte minutos de descartes.