Redis es un almacén de datos en memoria. Salvatore Sanfilippo lo publicó en 2009.
En 2024 pasó a licencia dual SSPLv1/RSALv2. El fork comunitario Valkey, mantenido por Linux Foundation, AWS y Google, sigue bajo licencia BSD.
El problema que resuelve
Cuando una web WordPress o un ERP se vuelven lentos, rara vez es la base de datos relacional la que se satura.
El cuello de botella suele estar en otros sitios:
- Las sesiones PHP se escriben como ficheros en disco.
- Los menús y widgets se consultan decenas de veces por petición.
Redis ataca justo ese flanco. Mantiene esa información volátil en RAM con latencias de microsegundos. Así el motor SQL hace solo lo que de verdad le toca.
Nació en 2009 como proyecto personal y hoy supera las 64.000 estrellas en GitHub. Empezó como una caché clave-valor sencilla y creció hasta ofrecer estructuras avanzadas: sorted sets, streams y pub/sub. También funciona como broker de mensajes ligero o cola de tareas.
Cómo encaja en una pila web
En WordPress se conecta con el plugin oficial redis-cache. Este sustituye el object cache por defecto y reduce las consultas SQL entre un 50% y un 70% según el caso. La mejora se nota más en webs con WooCommerce o multilenguaje.
En PHP genérico (Dolibarr, Symfony) se configura como session.save_handler en php.ini. Así las sesiones dejan de depender del filesystem. Es casi obligatorio cuando hay más de un contenedor PHP detrás de un balanceador.
La persistencia es opcional y admite dos modos:
- Snapshots RDB: copias cada N minutos para datos que pueden perderse.
- AOF (append-only file): cuando hace falta durabilidad real.
En cachés de sesión normalmente basta con RDB.
Cómo lo aplicamos en SMedialab
Lo añadimos a cualquier deploy Docker multi-contenedor con PHP detrás: WordPress, Dolibarr o integraciones a medida. Resuelve el bug clásico de sesiones que se pierden cuando el balanceador rota peticiones entre contenedores.
Donde NO lo recomendamos es en webs WordPress sencillas, con tráfico moderado y hosting compartido Hestia. Ahí el cache de objetos de WordPress más un buen plugin de page cache resuelven igual, sin sumar otra pieza al stack.
Casos típicos en nuestros clientes
Un hostal pequeño en La Laguna con WooCommerce arrastraba caídas de carrito al cambiar de página. La base de datos servía 130 consultas por petición. Activamos Redis como object cache y bajaron a 18. El TTFB pasó de 1,8 s a 320 ms.
Una agencia de excursiones tenía dos instancias PHP detrás de Traefik. Redis fue la pieza que permitió desactivar las sesiones sticky en el balanceador. Así repartimos el tráfico de forma uniforme sin perder al cliente a mitad de reserva.
Si el TTFB de tu web tiene picos a primera hora o tras subidas de tráfico, lo revisamos como parte del alojamiento web gestionado.
