Migración exitosa: cuatro nodos PHP-FPM detrás de un balanceador de carga, sesiones en Redis, despliegues sin desconexiones masivas. Corte de la red de Redis un martes a las 11 a.m.: 100% de los usuarios volvieron a conectarse, los carritos de compras se vaciaron, los tickets de soporte se multiplicaron por doscientos. El monitoreo alertó al procesador PHP, no a la memoria de Redis ni a las conexiones rechazadas.
Este escenario ilustra el escalado clásico: Redis for Sessions resuelve el escalado horizontal, pero crea una dependencia crítica si se trata como un "caché desechable". La sesión no es una página HTML recalculable: es el estado actual del usuario: carrito de compras, paso de autenticación segura, asistente de varias páginas.
Los equipos que migran a Redis sin un plan de recuperación a menudo descubren que su panel monitorea la CPU de PHP, no la memoria de Redis ni las conexiones rechazadas. Sin embargo, una falla de Redis se manifiesta primero con errores 500 en la conexión, no con una alerta de disco lleno.
Muchos equipos descubren el problema el día de la primera interrupción de Redis, no el día de la migración. Antes de agregar Redis, la pregunta no es simplemente "¿cómo configurar PHP?" » pero “¿qué pasa si Redis desaparece durante cinco minutos? ¿Y quién recibe la alerta? »
La respuesta debe estar escrita: conmutación por error de Sentinel, restauración desde AOF o página de mantenimiento explícita. Sin un procedimiento, la interrupción de Redis se convierte en una interrupción total del negocio: carritos de compras perdidos, autenticación segura interrumpida y soporte saturado en unos minutos.
Arquitectura saludable
| Componente | Recomendación |
|---|---|
| Instancia | Sesiones de Redis dedicadas o base 1 separadas del caché |
| Persistencia | AOF para recuperación; sesiones tienen un TTL de todos modos |
| ja | Sentinel (3 nodos) o Redis Cluster si la carga es alta |
| Red | Red privada, no Redis en la Internet pública |
| PHP | session.save_handler=redis, session.save_path=tcp://... |
Configuración PHP ilustrativa:
session.save_handler = redis
session.save_path = "tcp://127.0.0.1:6379?database=1&timeout=2&prefix=sess:"
sesión.gc_maxlifetime = 3600
Breve demora en la conexión de Redis: es mejor fallar rápidamente que bloquear PHP-FPM durante treinta segundos.
Caché de Redis frente a sesiones de Redis: no mezclar
| Uso | TTL | Desalojo |
|---|---|---|
| Caché de aplicaciones | Varía | allkeys-lru aceptable |
| Sesiones | Actividad móvil del usuario | volatile-lru o noeviction |
Un FLUSHDB accidental en la caché compartida provoca una desconexión global. Instancias separadas o, como mínimo, índices base.
Alternativa: esperanza versus planificación
Opciones realistas:
- Redis alta disponibilidad: modelo principal.
- Plegar archivos si Redis no está disponible: rompe el equilibrio sin afinidad; aceptable en una emergencia breve.
- Degradación monitoreada: inicie sesión en la página de mantenimiento si falla la verificación de estado de Redis.
No prometa "respaldo de archivos transparente" en cuatro nodos sin afinidad de sesión.
Monitoreo
Monitorear clientes_conectados, memoria_usada, conexiones_rechazadas. Mida la latencia con redis-cli --latency. Alerta si el maestro cae (Sentinel). Correlacione los picos de error 5xx en la conexión con el estado de Redis.
Lado del alojamiento: Redis administrado (OVH, Scaleway) o contenedor dedicado en VPS, no Redis en la misma máquina virtual que PHP sin límites estrictos de memoria. Consulte también Redis o Memcached y Grupo de conexiones.
Planifique también un ejercicio de recuperación: detener Redis en preproducción, medir el tiempo antes de restaurar el servicio y verificar que el equipo sepa quién activa el cambio Sentinel. Sin este ejercicio, la alta disponibilidad sigue siendo una línea en un diagrama arquitectónico.
Arriba: la sesión de Redis no es un caché, es memoria de usuario
Antes de las sesiones de Redis: pruebe detener Redis en preproducción y cronometre el impacto. Después: documente un procedimiento de recuperación en menos de quince minutos o una conmutación por error de Sentinel probada; sin documentación, la interrupción se convierte en una crisis.
Decide y avanza sin puntos ciegos
Reserve una instancia dedicada a sesiones, configure Sentinel o Redis administrado de alta disponibilidad antes de la producción de múltiples nodos y conecte una verificación del estado de la aplicación con alertas de Redis. Pruebe una interrupción simulada cada trimestre y prohíba cualquier "FLUSH" sin un procedimiento escrito; la desconexión masiva a menudo ocurre como un gesto administrativo, no como un ataque.
Preguntas frecuentes
¿Redis es adecuado para sesiones PHP?
Sí: baja latencia, TTL nativo, uso compartido entre nodos PHP. Prefiera una instancia dedicada para sesiones o un índice base separado en lugar de mezclar caché y sesiones en las mismas claves.
¿Qué sucede si Redis no está disponible?
Por defecto, desconexión masiva. Planifique la persistencia de Sentinel, Cluster, AOF o un respaldo documentado con sus limitaciones.
¿Deberían cifrarse las sesiones en Redis?
Si los datos son confidenciales, cifre en el lado de la aplicación y use una red privada con ACL mínima.
¿Sesiones de Redis frente a sesiones fijas?
Redis permite PHP sin estado local; la afinidad por sí sola es frágil cuando se vuelve a implementar un nodo.
Las sesiones de Redis escalan tu PHP, siempre y cuando no trates el estado del usuario como un caché desechable.