Cómo instalar Redis como caché en Ubuntu 24.04

Redis es un almacén de datos en memoria que responde en microsegundos, lo que lo convierte en la opción habitual para cachear resultados de consultas a base de datos, respuestas de APIs externas o fragmentos de páginas. En este tutorial instalarás Redis en Ubuntu 24.04 y lo configurarás específicamente como caché: con un límite de memoria, una política que expulsa las claves menos usadas cuando se llena, sin persistencia en disco y protegido con contraseña. Al final lo usarás desde una aplicación Python con el patrón cache-aside.

Requisitos previos

• Un servidor con Ubuntu 24.04 LTS, por ejemplo un VPS de CubePath.
• Un usuario no root con privilegios sudo.
• Memoria suficiente para la caché además de lo que usa tu aplicación. En esta guía se reservan 256 MB para Redis; ajústalo a tu caso.
• Python 3 con el módulo venv para el ejemplo del paso 6 (sudo apt install python3-venv).

Paso 1: Instalar Redis

El repositorio de Ubuntu 24.04 incluye Redis 7.0, que recibe actualizaciones de seguridad de Ubuntu y es suficiente para usarlo como caché. Instálalo:

sudo apt update
sudo apt install redis-server

El servicio se habilita y arranca automáticamente. Comprueba su estado:

sudo systemctl status redis-server

● redis-server.service - Advanced key-value store
     Loaded: loaded (/usr/lib/systemd/system/redis-server.service; enabled; preset: enabled)
     Active: active (running) since Thu 2026-09-25 10:05:12 UTC; 8s ago

Comprueba que responde:

redis-cli ping

PONG

Por defecto Redis solo escucha en 127.0.0.1 y ::1, así que aún no es accesible desde fuera del servidor:

sudo ss -tlnp | grep 6379

LISTEN 0      511        127.0.0.1:6379      0.0.0.0:*    users:(("redis-server",pid=2143,fd=6))
LISTEN 0      511            [::1]:6379         [::]:*    users:(("redis-server",pid=2143,fd=7))

Paso 2: Limitar la memoria y elegir la política de expulsión

Sin límite, Redis crece hasta agotar la RAM del servidor. Como caché, lo correcto es fijar un máximo y dejar que Redis expulse claves antiguas cuando lo alcance. La configuración está en /etc/redis/redis.conf:

sudo nano /etc/redis/redis.conf

Busca las directivas maxmemory y maxmemory-policy (con Ctrl+W en nano), que vienen comentadas, y déjalas así:

maxmemory 256mb
maxmemory-policy allkeys-lru

Con allkeys-lru, cuando se alcanza el límite Redis elimina las claves usadas hace más tiempo, tengan o no caducidad. Las alternativas más habituales para caché son:

Paso 3: Desactivar la persistencia en disco

Una caché se puede reconstruir desde el origen, así que guardarla en disco solo añade escrituras y pausas por fork(). En el mismo archivo, busca la sección SNAPSHOTTING y añade esta línea para desactivar las instantáneas RDB:

save ""

Comprueba también que el registro AOF sigue desactivado, que es el valor por defecto:

appendonly no

Nota

si además de caché usas este Redis para sesiones de usuario o colas, no desactives la persistencia; en ese caso lo recomendable es una instancia separada para cada uso.

Paso 4: Proteger Redis con una contraseña

Aunque Redis solo escuche en local, cualquier proceso del servidor podría leer o borrar la caché. Genera una contraseña larga y aleatoria:

openssl rand -base64 32

k3Vq9uG1pXhS0rN2yT7bW4eZ8aC6dF5jL1mQ3oR9s0U=

En /etc/redis/redis.conf, busca requirepass y añade la contraseña generada en lugar de your_strong_password:

requirepass your_strong_password

El archivo contiene ahora una credencial. En Ubuntu ya es legible solo por el usuario redis y el grupo redis; compruébalo:

ls -l /etc/redis/redis.conf

-rw-r----- 1 redis redis 106545 Sep 25 10:12 /etc/redis/redis.conf

Guarda el archivo, reinicia Redis para aplicar todos los cambios y comprueba que arranca bien:

sudo systemctl restart redis-server
sudo systemctl status redis-server --no-pager

Sin autenticarse, Redis ya rechaza los comandos:

redis-cli ping

(error) NOAUTH Authentication required.

Para trabajar con redis-cli sin escribir la contraseña en la línea de comandos (quedaría en el historial y en la lista de procesos), cárgala en la variable REDISCLI_AUTH, que redis-cli lee automáticamente. read -rs la pide sin mostrarla:

read -rs REDISCLI_AUTH && export REDISCLI_AUTH
redis-cli ping

PONG

Verifica que la configuración de los pasos 2 y 3 está activa:

redis-cli CONFIG GET 'maxmemory*'

1) "maxmemory-policy"
2) "allkeys-lru"
3) "maxmemory"
4) "268435456"

268435456 bytes son los 256 MB configurados. Comprueba también que las instantáneas están desactivadas:

redis-cli CONFIG GET save

1) "save"
2) ""

Paso 5: Ajustar el kernel para Redis

Redis registra un aviso al arrancar si vm.overcommit_memory no vale 1, porque sin él un fork() puede fallar con poca memoria libre. Compruébalo en el log:

sudo grep -i overcommit /var/log/redis/redis-server.log

Si aparece el aviso, aplica el ajuste de forma persistente:

echo "vm.overcommit_memory = 1" | sudo tee /etc/sysctl.d/60-redis.conf
sudo sysctl --system
sudo systemctl restart redis-server

Comprueba el valor:

sysctl vm.overcommit_memory

vm.overcommit_memory = 1

Paso 6: Usar Redis como caché desde una aplicación

El patrón más común es cache-aside: la aplicación busca primero en Redis; si no encuentra la clave (fallo de caché), obtiene el dato del origen y lo guarda en Redis con un tiempo de vida (TTL). El TTL garantiza que los datos obsoletos desaparecen solos.

Crea un proyecto con un entorno virtual e instala el cliente oficial de Python:

mkdir ~/cache-demo
cd ~/cache-demo
python3 -m venv .venv
.venv/bin/pip install redis

Crea el script de ejemplo:

nano ~/cache-demo/cache_demo.py

import json
import os
import time

import redis

r = redis.Redis(
    host="127.0.0.1",
    port=6379,
    password=os.environ["REDIS_PASSWORD"],
    decode_responses=True,
)


def consulta_lenta(user_id):
    """Simula una consulta costosa a la base de datos."""
    time.sleep(2)
    return {"id": user_id, "nombre": f"usuario{user_id}"}


def obtener_usuario(user_id):
    clave = f"user:{user_id}"
    cacheado = r.get(clave)
    if cacheado is not None:
        return json.loads(cacheado)

    datos = consulta_lenta(user_id)
    r.set(clave, json.dumps(datos), ex=300)  # caduca en 5 minutos
    return datos


for intento in (1, 2):
    inicio = time.perf_counter()
    usuario = obtener_usuario(42)
    print(f"Intento {intento}: {usuario} en {time.perf_counter() - inicio:.3f} s")

Ejecuta el script pasando la contraseña en una variable de entorno (en producción la leerás de la configuración o de un gestor de secretos):

read -rs REDIS_PASSWORD && export REDIS_PASSWORD
.venv/bin/python cache_demo.py

Intento 1: {'id': 42, 'nombre': 'usuario42'} en 2.004 s
Intento 2: {'id': 42, 'nombre': 'usuario42'} en 0.001 s

El primer intento es un fallo de caché y tarda lo que la consulta; el segundo se sirve desde Redis. Comprueba la clave y su tiempo de vida restante:

redis-cli GET user:42
redis-cli TTL user:42

"{\"id\": 42, \"nombre\": \"usuario42\"}"
(integer) 287

Cuando el dato cambie en el origen, bórralo de la caché para que la siguiente lectura lo recargue:

redis-cli DEL user:42

En tu aplicación harás lo mismo con r.delete(clave) justo después de actualizar la base de datos.

Paso 7: Medir la eficacia de la caché

La tasa de aciertos indica si la caché realmente ahorra trabajo. Redis cuenta los aciertos y fallos desde el último arranque:

redis-cli INFO stats | grep -E 'keyspace_(hits|misses)|evicted_keys'

keyspace_hits:1
keyspace_misses:1
evicted_keys:0

La tasa de aciertos es hits / (hits + misses). En una caché bien dimensionada suele superar el 80 %. Si evicted_keys crece rápido y la tasa es baja, la memoria asignada se queda corta: sube maxmemory. Consulta el uso de memoria actual con:

redis-cli INFO memory | grep -E 'used_memory_human|maxmemory_human|maxmemory_policy'

used_memory_human:1.02M
maxmemory_human:256.00M
maxmemory_policy:allkeys-lru

Acceso desde otro servidor (opcional)

Si la aplicación está en otro servidor, no expongas Redis a Internet: úsalo solo a través de una red privada. Añade la IP privada del servidor de Redis a la directiva bind de /etc/redis/redis.conf, sustituyendo your_private_ip:

bind 127.0.0.1 -::1 your_private_ip

Reinicia Redis y permite el puerto 6379 únicamente desde la IP del servidor de aplicación (app_server_ip):

sudo systemctl restart redis-server
sudo ufw allow from app_server_ip to any port 6379 proto tcp

Redis no cifra el tráfico en esta configuración, por eso la red debe ser privada.

Solución de problemas

(error) NOAUTH Authentication required. El cliente no ha enviado la contraseña. En redis-cli, exporta REDISCLI_AUTH como en el paso 4; en la aplicación, revisa el parámetro password del cliente.

OOM command not allowed when used memory > 'maxmemory'. La política de expulsión es noeviction, así que Redis rechaza escrituras al llenarse. Comprueba con redis-cli CONFIG GET maxmemory-policy que el cambio del paso 2 se aplicó y que editaste el archivo correcto.

Redis no arranca tras editar la configuración. Normalmente es una directiva mal escrita. El log indica la línea exacta:

sudo journalctl -u redis-server -n 30 --no-pager
sudo tail -n 30 /var/log/redis/redis-server.log

Could not connect to Redis at your_private_ip:6379: Connection refused desde otro servidor. Redis no escucha en esa IP o UFW bloquea el puerto. Comprueba con sudo ss -tlnp | grep 6379 en qué direcciones escucha y con sudo ufw status que existe la regla para la IP de origen.

Conclusión

Has instalado Redis en Ubuntu 24.04 y lo has configurado como caché de aplicación: memoria limitada con expulsión LRU, sin persistencia en disco, protegido con contraseña y en uso desde Python con el patrón cache-aside. Como siguientes pasos puedes crear usuarios ACL con permisos limitados para cada aplicación en lugar de una contraseña compartida, integrar Redis como backend de caché de tu framework (Django, Laravel o Rails lo soportan de serie) y vigilar evicted_keys y la tasa de aciertos desde tu sistema de monitorización.