Redis para Moodle: Caché en Memoria Explicado

Más de un administrador de Moodle, al mirar atrás sobre las mejoras de rendimiento que realmente marcaron la diferencia en su instalación, coincide en la misma conclusión: instalar Redis fue la mejora individual más grande que hicieron, especialmente si el servidor todavía usaba discos duros tradicionales en vez de SSD.

En esta guía vas a ver qué es exactamente Redis, por qué mejora tanto el rendimiento frente a la configuración por defecto de Moodle, y cómo configurarlo correctamente para sacarle todo el partido sin caer en el error más común al hacerlo.

Qué es Redis y qué problema resuelve

Redis es un almacén de datos en memoria, de código abierto, usado como base de datos, caché y motor de mensajería por millones de desarrolladores. En el contexto de Moodle, su función principal es sustituir la caché por defecto (que en gran parte vive en disco, dentro de la carpeta moodledata) por almacenamiento en memoria RAM, muchísimo más rápido de leer y escribir.

Moodle usa caché para dos propósitos principales que Redis puede gestionar:

• Sesiones de usuario: qué usuario está conectado, en qué estado, con qué permisos activos en ese momento.
• Caché de aplicación (MUC, Moodle Universal Cache): estructuras de curso, preferencias de usuario, datos de tema y otra información consultada con mucha frecuencia que no cambia constantemente.

Aunque el intro los mete en la misma frase, conviene tener claro desde el principio que son dos mecanismos distintos, con dos sitios de configuración distintos: las sesiones se activan en config.php, y la caché de aplicación se configura por interfaz, en la administración del sitio. Puedes tener uno sin el otro. Más abajo verás cada uno por separado.

Redis frente a la caché en disco: por qué gana la memoria

Por defecto, Moodle guarda buena parte de su caché en el sistema de archivos, dentro de moodledata/cache y moodledata/localcache, y las sesiones en moodledata/sessions. El almacén de archivos (cachestore_file) funciona, pero paga un peaje en cada lectura y escritura: abrir el archivo, obtener un bloqueo, leer del disco, cerrar. En un servidor con discos mecánicos, o peor, con moodledata montado sobre almacenamiento de red (NFS), ese peaje se nota en cada clic de cada usuario.

Redis vive en RAM. Una lectura en memoria se mide en microsegundos; una lectura de disco mecánico, en milisegundos, tres órdenes de magnitud de diferencia. Y no es solo la latencia bruta: Redis evita el sobrecoste del sistema de archivos (metadatos, stat, bloqueos de fichero) que se multiplica cuando decenas de usuarios golpean la caché a la vez. Por eso el salto es tan visible en instalaciones que todavía no están sobre SSD/NVMe, y por eso quien lo instala en ese escenario lo recuerda como la mejora que más se notó.

Ahora bien, conviene ser honesto con lo que Redis mejora y lo que no. Lo desarrollamos al final del artículo, pero adelanto la idea: Redis acelera sesiones y caché de aplicación, no las consultas de contenido ni la entrega de archivos grandes. No es una varita mágica; es una pieza que quita un cuello de botella concreto.

Por qué Redis es mejor que Memcached para Moodle

Aunque Moodle admite varios motores de caché (archivo, base de datos, Memcached, APCu, MongoDB, Redis), Redis es generalmente la opción recomendada frente a Memcached por sus mejores características de seguridad y por tratarse de un proyecto más activo y actualizado.

Cómo configurar Redis para sesiones

Las sesiones no se tocan por interfaz: se activan editando config.php, el archivo de configuración de Moodle en la raíz de la instalación. En su forma mínima:

$CFG->session_handler_class = '\core\session\redis';
$CFG->session_redis_host = '127.0.0.1';
$CFG->session_redis_port = 6379;
$CFG->session_redis_database = 0;

En un entorno real querrás algunas líneas más. Si Redis tiene contraseña (algo recomendable en cuanto no esté aislado en localhost), y si compartes la misma instancia entre varios servicios, conviene fijar un prefijo de claves para no pisarte con otras aplicaciones:

$CFG->session_redis_auth = 'tu-contraseña-redis';
$CFG->session_redis_prefix = 'moodle_prod_';
$CFG->session_redis_acquire_lock_timeout = 120;
$CFG->session_redis_lock_expire = 7200;

session_redis_database te permite separar lógicamente las sesiones en un número de base de datos de Redis (0–15 por defecto) distinto al de la caché de aplicación, algo útil si por lo que sea acabas usando la misma instancia física. El bloqueo de sesión (acquire_lock_timeout) evita condiciones de carrera cuando el mismo usuario dispara varias peticiones simultáneas; si lo pones demasiado bajo verás errores de “no se pudo obtener el bloqueo de sesión” bajo carga.

Cómo configurar Redis como caché de aplicación

La caché de aplicación (MUC) sí se configura por interfaz, y es un paso independiente del anterior. Después de instalar y activar Redis a nivel de servidor:

1. Ve a Administración del sitio > Complementos > Caché > Configuración (Site administration > Plugins > Caching > Configuration).
2. En Instalación de almacenes de caché (Installed cache stores), localiza Redis y pulsa Añadir instancia.
3. Dale un nombre descriptivo (p. ej. redis-app), indica el servidor (127.0.0.1:6379 o la ruta del socket), la contraseña si la hay y un prefijo de clave. Guarda.
4. Baja hasta Almacenes usados cuando no hay una asignación (Stores used when no mapping is present) y cambia el desplegable de Aplicación (Application) de “Caché de archivos por defecto” a tu nueva instancia Redis. Puedes hacer lo mismo con Sesión (Session).

Un matiz que se pasa por alto: no mapees la caché de Petición (Request) a Redis. Esa caché vive dentro de una única petición PHP en memoria del propio proceso; enviarla a Redis solo añade viajes de red que no aportan nada. Déjala en su almacén por defecto.

El error que solo se comete una vez: mezclar políticas de expulsión

Este es el detalle técnico que marca la diferencia entre una configuración de Redis que funciona bien y una que provoca un incidente inesperado: sesiones y caché de aplicación no deberían compartir la misma política de expulsión de memoria.

• Sesiones: usa la política noeviction. Si Redis se queda sin memoria, es preferible que devuelva un error visible a que empiece a descartar sesiones de usuarios activos sin ningún aviso, perder sesiones silenciosamente puede traducirse en usuarios desconectados de golpe en mitad de un examen o una entrega.
• Caché de aplicación (MUC): puede usar allkeys-lru sin problema, porque Moodle regenera esta información automáticamente en la siguiente petición si se expulsa de la caché, no hay pérdida de datos real, solo una recomputación puntual.

La forma más segura de aplicar esto es ejecutar dos instancias de Redis separadas, cada una con su propia política, en vez de una única instancia compartida con una configuración de compromiso que no es óptima para ninguno de los dos casos.

Resumido en una tabla, para que se vea de un golpe por qué no conviene mezclarlos:

Uso	Qué guarda	Política de expulsión	Qué pasa si Redis se llena
Sesiones	Quién está conectado, permisos activos, estado de cada usuario	noeviction	Devuelve un error visible; no descarta ninguna sesión activa. El sitio avisa en vez de tirar usuarios en silencio.
Caché de aplicación (MUC)	Estructuras de curso, preferencias, datos de tema, definiciones cacheadas	allkeys-lru	Expulsa las claves menos usadas recientemente. Moodle regenera ese dato en la siguiente petición. Sin pérdida real, solo una recomputación puntual.

La lectura de la tabla es directa: una sesión perdida es un usuario expulsado de un examen; una clave de MUC perdida es una consulta extra de milisegundos. Aplicar allkeys-lru a las sesiones significa aceptar el primer riesgo para ahorrarte el segundo, que era despreciable. No compensa. Por eso, si de verdad solo puedes levantar una instancia, la política segura para esa instancia compartida es noeviction y vigilar la memoria de cerca, nunca allkeys-lru.

Requisitos previos antes de instalar Redis

• Memoria RAM suficiente en el servidor para alojar el conjunto de datos cacheados sin competir con otros procesos críticos.
• La extensión de PHP para Redis instalada y activa en el servidor.
• Redis instalado y en ejecución como servicio, accesible desde el servidor de Moodle (localmente o en un servidor dedicado, según la escala de la instalación).

Cuándo separar Redis en un servidor propio

Para instalaciones pequeñas y medianas, Redis puede convivir perfectamente en el mismo servidor que Moodle. A partir de varios cientos de usuarios concurrentes, o cuando la instalación crece hacia una arquitectura con base de datos separada, mover Redis a su propio nodo evita que la memoria y el procesamiento de la caché compitan con el resto de servicios del servidor principal.

Redis como estado compartido entre varios servidores

Hay un escenario donde Redis deja de ser “una mejora recomendable” y pasa a ser prácticamente obligatorio: cuando Moodle deja de vivir en una sola máquina y se reparte entre varios nodos web detrás de un balanceador. Es el camino natural cuando la matriculación de un curso o una convocatoria FUNDAE dispara la concurrencia por encima de lo que aguanta un solo servidor.

En ese momento, las sesiones en disco local dejan de servir: si el usuario inicia sesión en el nodo A y el balanceador manda su siguiente petición al nodo B, el nodo B no encuentra su sesión y lo echa. La solución tradicional (“sticky sessions”, atar a cada usuario a un nodo fijo) reparte mal la carga y cae con el nodo. Redis resuelve esto de raíz: al ser un almacén de sesiones compartido y externo, cualquier nodo ve la sesión de cualquier usuario. Lo mismo aplica a la MUC: un Redis compartido evita que cada nodo reconstruya su propia caché por separado y que las invalidaciones de un nodo no lleguen a los demás.

Si tu Moodle va por ese camino, Redis no es opcional: es la pieza que hace posible escalar horizontalmente. Lo tratamos con más detalle en escalar Moodle para picos de alumnos, donde el estado compartido entre nodos es uno de los pilares.

Qué mejora Redis de verdad, y qué no

Para no vender humo: Redis quita un cuello de botella concreto, no todos. Mejora de forma clara el tiempo de lectura/escritura de sesiones y de la caché de aplicación, que en un Moodle cargado son operaciones constantes en cada página. Si tu lentitud viene de ahí (muchos usuarios navegando, mucha lectura de estructura de curso y preferencias), se nota.

Lo que Redis no arregla: consultas pesadas contra la base de datos (informes enormes, cálculo de calificaciones de un curso masivo), la entrega de vídeos y archivos grandes (eso sale de moodledata/filedir, no de la caché), o un PHP sin OPcache. Instalar Redis en un servidor cuyo verdadero problema es la base de datos o el disco de contenidos no cambiará gran cosa. Antes de instalarlo conviene saber de dónde viene la lentitud; lo explicamos en rendimiento y optimización de Moodle, donde Redis es una pieza más dentro de un conjunto (OPcache, base de datos, servidor web) que hay que afinar en orden.

Errores comunes al implementar Redis en Moodle

• Usar una única instancia de Redis con la misma política de expulsión para sesiones y caché de aplicación.
• No verificar que la extensión de PHP para Redis está instalada antes de configurar Moodle, provocando errores de conexión.
• No monitorizar el uso de memoria de Redis, arriesgándose a que se llene sin previo aviso si la política de sesiones es noeviction y no hay margen suficiente.
• Instalar Redis pero no cambiar la asignación de caché en Moodle, dejando la configuración nueva sin efecto real porque el sitio sigue usando el almacén de archivos por defecto.

Preguntas frecuentes

¿Redis sustituye a la base de datos de Moodle? No, Redis complementa a la base de datos gestionando sesiones y ciertos datos de caché de acceso muy frecuente, pero Moodle sigue dependiendo de su base de datos principal para el contenido y las calificaciones.

¿Necesito dos servidores Redis separados? No es obligatorio, pero sí recomendable usar dos instancias con políticas de expulsión distintas para sesiones y caché de aplicación, para evitar el riesgo de perder sesiones activas sin aviso.

¿Redis o Memcached para Moodle? Redis es generalmente la opción preferida, por mejores características de seguridad y por ser un proyecto más activamente mantenido.

¿Qué pasa si Redis se queda sin memoria con la política noeviction? Devuelve un error explícito en vez de descartar datos silenciosamente, lo que te permite detectar el problema y ampliar recursos antes de que afecte a usuarios de forma invisible.

¿Instalar Redis mejora el rendimiento automáticamente? Solo si además configuras Moodle para usarlo como almacén de caché de sesión y aplicación desde Site administration > Plugins > Caching, instalarlo sin esa asignación no tiene ningún efecto.

¿Redis es necesario en instalaciones pequeñas? Aporta beneficio incluso en instalaciones pequeñas, especialmente si el almacenamiento en disco no es SSD/NVMe, aunque el impacto relativo es mayor cuanto más crece la concurrencia.

¿Cómo sé si mi configuración de Redis está funcionando correctamente? Verificando en Site administration > Plugins > Caching > Configuration que las cachés de sesión y aplicación están efectivamente mapeadas a la instancia de Redis, y monitorizando el uso de memoria del servicio.

¿Cuánta memoria RAM necesita Redis para Moodle? Depende del tamaño del sitio y de los usuarios concurrentes, pero la clave es reservar un maxmemory con margen sobre el conjunto de datos que realmente cacheas, no dejarlo sin límite. Con la caché de aplicación en allkeys-lru puedes acotar la memoria y dejar que expulse lo menos usado; con las sesiones en noeviction, en cambio, necesitas margen de sobra para no quedarte sin espacio y empezar a devolver errores. Monitoriza el uso real durante unas semanas y ajusta a partir de datos, no de una cifra inventada.

¿Puedo usar el mismo Redis para sesiones y caché de aplicación separándolos por número de base de datos? Puedes, usando session_redis_database y un número distinto para la MUC, pero sigues compartiendo la misma política de expulsión y la misma memoria del proceso. Separar por base de datos organiza las claves, no protege las sesiones de una expulsión allkeys-lru. Si de verdad quieres seguridad, la separación tiene que ser por instancia, cada una con su política, no por número de base de datos.

¿Redis pierde todos los datos si se reinicia el servidor? Redis es en memoria, así que un reinicio sin persistencia vacía la caché. Para la MUC no es grave: Moodle la regenera. Para las sesiones sí importa: un reinicio dejaría a todos los usuarios sin sesión. Si eso es un problema en tu caso, Redis admite persistencia (RDB/AOF); aun así, un reinicio de Redis en producción conviene planificarlo en horario de baja actividad.

¿Hace falta reiniciar Moodle o Apache tras cambiar la configuración de caché? No para la MUC: los cambios en Administración del sitio > Complementos > Caché se aplican al guardar. Los cambios en config.php (las sesiones) sí surten efecto en las nuevas peticiones sin reiniciar el servidor web, aunque las sesiones ya abiertas seguirán en el almacén anterior hasta que caduquen.

Conclusión

Redis es, según la experiencia repetida de quienes lo han implementado, una de las mejoras de rendimiento con mayor impacto real en una instalación de Moodle, pero solo si se configura con el detalle correcto: políticas de expulsión distintas para sesiones y caché de aplicación, y la asignación efectiva desde la configuración de caché de Moodle, no solo la instalación del servicio.

Si prefieres que alguien configure esto correctamente por ti, en Avantys lo incluimos como parte de la optimización de cada Moodle que gestionamos. Puedes pedir una auditoría gratuita en Moodle Gestionado.

Artículos relacionados

• Mantenimiento y hosting Moodle: guía completa
• Por qué mi Moodle va lento: causas más comunes
• OPcache en Moodle: qué es y cómo configurarlo
• Requisitos de servidor para Moodle (CPU, RAM, disco)

---