Después de cambiar a dos servidores web, los usuarios se desconectan aleatoriamente. La causa: un único Redis configurado en maxmemory-policy allkeys-lru, donde el caché desaloja las claves session:* bajo carga. El equipo había "agregado Redis" sin elegir qué papel desempeña en la arquitectura.
Este escenario se repite tan pronto como se implementa una herramienta eficaz como solución genérica. Redis es un motor en memoria de uso general, no un solo producto con un modo predeterminado. La caché, el almacenamiento de sesiones y el intermediario de mensajes comparten el protocolo, pero no los requisitos de durabilidad o desalojo.
Redis acelera lo que decides guardar en la memoria. Mal configurado, también acelera tus incidencias: desconexiones masivas, correos electrónicos nunca enviados, datos obsoletos servidos durante horas. Por tanto, la pregunta preliminar no es “¿necesitamos Redis?” » pero “¿qué trabajo debería proporcionar Redis y con qué reglas si la memoria se satura? »
Tres usos: tres contratos
Cada uso impone un contrato diferente entre volatilidad, desalojo y persistencia.
| Uso | Volatilidad OK | Desalojo | Persistencia |
|---|---|---|---|
| Caché de objetos | Sí | LRU/LFU a menudo | No |
| Sesión de usuario | No | no desalojo o instancia dedicada | AOF recomendado |
| Cola | No | no desalojo | AOF + trabajadores absolución |
Caché: resultados de consultas SQL, fragmentos HTML, contadores de limitación de velocidad. Recalculable si falta.
Sesiones: carrito de compras, conexión PHP/Laravel/Symfony, lista negra de tokens. Desaparición = experiencia catastrófica.
Cola — Laravel Horizon, Sidekiq, Bull: correos electrónicos, miniaturas. Pérdida = mensajes nunca dejados.
Un Redis que desaloja sesiones para liberar espacio para el caché es un error arquitectónico, no un ajuste.
Patrones de integración
PHP/Laravel — configura SESSION_DRIVER=redis y CACHE_DRIVER=redis con dos conexiones separadas y prefijos separados (app_session:, app_cache:).
Nodo: use connect-redis para sesión rápida y ioredis para caché con TTL explícito en cada clave.
Trabajadores: colocan a los consumidores en procesos separados de la web; Mismo Redis para la cola, escalado horizontal de trabajadores.
Caché TTL: siempre establece una duración; Evite claves huérfanas sin caducidad.
Para conocer la capa SQL subyacente, consulte MySQL para sitio dinámico. Si duda entre un alojamiento gestionado y un servidor dedicado, la guía PaaS o servidor le ayudará a situar a Redis en el conjunto.
Dimensionamiento y alta disponibilidad
Dimensione la RAM: tamaño del conjunto de datos más un margen de entre un veinte y un treinta por ciento, incluidos los picos de cola. Sin intercambio en Redis: la latencia se vuelve explosiva. Para sesiones críticas de varios nodos, considere Redis Sentinel o una oferta administrada (ElastiCache, Scaleway, OVH). Haga una copia de seguridad de los archivos con AOF; el caché se puede reconstruir.
Compare las ofertas de Redis administradas en nuestro directorio.
Errores comunes
Redis expuesto en Internet: el puerto 6379 sin autenticación a menudo conduce a la minería de criptomonedas.
Claves sin espacio de nombres: colisión entre puesta en escena y producción.
*KEYS en producción**: bloquea todo el servidor.
Caché sin invalidación: datos obsoletos después de la actualización comercial.
Cola sin cola muerta: trabajos perdidos silenciosamente.
Lo mejor: Redis acelera, no parchea
Realice un perfil de SQL y sesiones antes de comprar cuatro gigabytes de Redis administrado. Mida también la tasa de desalojo después de una semana de carga real: un caché que desaloja claves útiles cada hora a menudo indica un tamaño de memoria insuficiente o una política de desalojo mal elegida para el rol asignado.
Decide y avanza sin puntos ciegos
Primero identifique la necesidad real (sesión de múltiples servidores, caché de objetos, cola o combinación) y luego separe las instancias y las políticas de desalojo por función. Configure la autenticación, vincule Redis a la red privada y niegue la exposición pública. Supervise la memoria y los desalojos, y documente las reglas de invalidación de la caché empresarial antes de considerar que la arquitectura es estable.
Preguntas frecuentes
¿Se requiere Redis para acelerar mi sitio?
No. Comience con caché HTTP, OPcache y consultas SQL optimizadas. Redis se vuelve relevante cuando necesita sesiones compartidas de múltiples servidores, almacenamiento en caché de objetos pesados o colas asíncronas.
¿Caché y sesión en el mismo Redis?
No recomendado en producción: la política de desalojo de caché puede desalojar claves de sesión. Instancias separadas o bases lógicas con políticas adecuadas.
¿Deberíamos habilitar la persistencia de Redis?
Para un caché puro, a menudo no. Para sesiones o colas, sí: AOF o Redis administrado con respaldo.
¿Administrado por Redis o en VPS?
Elija administrado si la alta disponibilidad, las copias de seguridad y los parches de seguridad están más allá de sus habilidades. Un VPS es adecuado para tráfico modesto con un control estricto de la memoria.
Redis: primero elija qué negocio (caché, sesión o archivo) antes de instalar una instancia general.