Almacén en memoria publicado en 2009 por Salvatore Sanfilippo. En 2024 cambió a licencia dual SSPLv1/RSALv2; el fork comunitario Valkey (mantenido por Linux Foundation, AWS y Google) sigue bajo BSD.
El problema que resuelve
Cuando una web WordPress o un ERP empiezan a notar lentitud no es habitualmente la base de datos relacional la que está saturada, sino las sesiones PHP escribiéndose como ficheros en disco y los menús/widgets consultándose decenas de veces por petición. Redis ataca exactamente ese flanco: mantiene esa información volátil en RAM con latencias de microsegundos, y deja al motor SQL hacer solo lo que de verdad le toca.
Lanzado en 2009 como proyecto personal y hoy con más de 64.000 estrellas en GitHub, Redis pasó de ser una caché clave-valor sencilla a un sistema con estructuras avanzadas (sorted sets, streams, pub/sub) que también funciona como broker de mensajes ligero o cola de tareas.
Cómo encaja en una pila web
Para WordPress se conecta vía el plugin oficial redis-cache que sustituye el object cache por defecto y reduce las consultas SQL en torno a un 50-70% según el caso, especialmente en webs con WooCommerce o multilenguaje. Para PHP genérico (Dolibarr, Symfony) se configura como session.save_handler en php.ini y elimina la dependencia del filesystem para sesiones, requisito casi obligatorio cuando hay más de un contenedor PHP detrás de un balanceador.
La persistencia es opcional: snapshots RDB cada N minutos para datos que pueden perderse y 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 donde haya PHP detrás (WordPress, Dolibarr, integraciones a medida): elimina 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 en hosting compartido Hestia — el cache de objetos de WordPress + 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, con TTFB pasando de 1,8 s a 320 ms. Para una agencia de excursiones con dos instancias PHP detrás de Traefik, Redis fue la pieza que permitió desactivar las sesiones sticky en el balanceador y repartir 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.
