Redis es un almacén de datos en memoria que responde en microsegundos, lo que lo convierte en la opción más habitual para cachear resultados de consultas a bases de datos, respuestas de APIs o sesiones. Una caché bien configurada reduce la carga de la base de datos y el tiempo de respuesta de la aplicación. En este tutorial instalarás Redis en Ubuntu 24.04, lo configurarás específicamente como caché (límite de memoria, expulsión de claves, sin persistencia y con contraseña) e implementarás el patrón cache-aside en una pequeña aplicación Python.

Requisitos previos

  • Un servidor con Ubuntu 24.04 LTS, por ejemplo un VPS de CubePath. Con 1 GB de RAM es suficiente para seguir el tutorial.
  • Un usuario no root con privilegios sudo.
  • Conocimientos básicos de Python para la parte de la aplicación de ejemplo.

Paso 1: Instalar Redis

Ubuntu 24.04 incluye Redis 7.0 en sus repositorios, con actualizaciones de seguridad durante todo el soporte de la versión. Instálalo:

sudo apt update
sudo apt install redis-server

El paquete redis-server instala también redis-tools, que incluye redis-cli y redis-benchmark. El servicio se habilita e inicia automáticamente. Compruébalo:

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 11:02:41 UTC; 6s ago

Haz una prueba de conexión:

redis-cli ping

PONG

Paso 2: Configurar Redis como caché

La configuración está en /etc/redis/redis.conf. Un Redis usado como caché tiene necesidades distintas de uno usado como base de datos: debe tener un tope de memoria, borrar claves antiguas cuando lo alcance y no necesita guardar los datos en disco, porque siempre se pueden regenerar desde la fuente original.

Genera una contraseña fuerte y guárdala; la usarás en este paso y en la aplicación:

openssl rand -base64 32

Abre el archivo de configuración:

sudo nano /etc/redis/redis.conf

Busca cada directiva (en nano, con Ctrl+W) y deja estos valores. Sustituye your_strong_password por la contraseña que acabas de generar:

# Escuchar solo en local (valor por defecto)
bind 127.0.0.1 -::1
protected-mode yes

# Exigir contraseña a los clientes
requirepass your_strong_password

# Tope de memoria para los datos de la caché
maxmemory 256mb

# Al llegar al tope, expulsar las claves menos usadas recientemente
maxmemory-policy allkeys-lru

# Caché pura: sin instantáneas RDB ni registro AOF
save ""
appendonly no

Ajusta maxmemory a tu servidor. Una referencia razonable en un servidor dedicado a Redis es entre el 50% y el 75% de la RAM, dejando el resto para el sistema y la sobrecarga del propio Redis.

La política de expulsión decide qué claves se borran al llegar al límite:

PolíticaQué claves expulsaCuándo usarla
noevictionNinguna, las escrituras fallan con errorRedis como base de datos (valor por defecto)
allkeys-lruLas usadas hace más tiempoCaché general, la opción recomendada
allkeys-lfuLas usadas con menos frecuenciaCaché con un grupo de claves muy populares y estable
volatile-lruLas usadas hace más tiempo, solo entre las que tienen TTLCaché y datos permanentes en la misma instancia
volatile-ttlLas que están más cerca de caducarCuando el TTL refleja bien la importancia de la clave

Reinicia Redis para aplicar los cambios:

sudo systemctl restart redis-server

Verifica que ahora exige contraseña. Sin autenticarte, cualquier comando devuelve un error:

redis-cli ping

(error) NOAUTH Authentication required.

Conéctate de forma interactiva y autentícate con AUTH, así la contraseña no queda en el historial del shell:

redis-cli

127.0.0.1:6379> AUTH your_strong_password
OK
127.0.0.1:6379> CONFIG GET maxmemory-policy
1) "maxmemory-policy"
2) "allkeys-lru"
127.0.0.1:6379> CONFIG GET maxmemory
1) "maxmemory"
2) "268435456"

Sal con exit.

Paso 3: Ajustar el kernel para Redis

Revisa el log de Redis tras el reinicio:

sudo tail -n 20 /var/log/redis/redis-server.log

Es habitual ver este aviso:

WARNING Memory overcommit must be enabled! Without it, a background save or replication may fail under low memory condition.

Redis crea un proceso hijo con fork() para guardar en disco y para replicar, y con la política de memoria por defecto del kernel esa operación puede fallar. Aunque en este tutorial la persistencia está desactivada, sigue siendo necesario si más adelante añades una réplica. Aplica el ajuste que recomienda Redis:

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

Reinicia Redis y comprueba que el aviso ha desaparecido del log:

sudo systemctl restart redis-server
sudo tail -n 20 /var/log/redis/redis-server.log

Paso 4: Probar la caché con redis-cli

Antes de escribir código, prueba las operaciones básicas de una caché. Conéctate con redis-cli y autentícate como en el paso 2:

127.0.0.1:6379> SET producto:42 '{"id":42,"nombre":"Teclado","precio":49.9}' EX 300
OK
127.0.0.1:6379> GET producto:42
"{\"id\":42,\"nombre\":\"Teclado\",\"precio\":49.9}"
127.0.0.1:6379> TTL producto:42
(integer) 296
127.0.0.1:6379> DEL producto:42
(integer) 1
127.0.0.1:6379> GET producto:42
(nil)
  • SET ... EX 300 guarda el valor con una caducidad de 300 segundos. En una caché, casi todas las claves deberían tener TTL.
  • TTL muestra los segundos que le quedan a la clave.
  • DEL invalida la clave, lo que harás cuando el dato original cambie.

Usa nombres de clave con prefijos separados por dos puntos (producto:42, usuario:17:perfil). Facilitan la lectura y permiten localizar grupos de claves con SCAN.

Paso 5: Implementar el patrón cache-aside en Python

El patrón más común es cache-aside: la aplicación busca primero en Redis; si la clave no existe (fallo de caché), consulta la base de datos, guarda el resultado en Redis con un TTL y lo devuelve. Las siguientes peticiones se sirven desde la caché hasta que la clave caduca o se invalida.

Instala el soporte de entornos virtuales y crea un proyecto:

sudo apt install python3-venv
mkdir ~/cache-demo && cd ~/cache-demo
python3 -m venv venv
source venv/bin/activate
pip install redis

Guarda la contraseña en una variable de entorno para no escribirla en el código:

read -rs REDIS_PASSWORD && export REDIS_PASSWORD

Escribe la contraseña y pulsa Intro (no se mostrará en pantalla). Ahora crea el programa:

nano 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,
)

CACHE_TTL = 300  # segundos


def get_product_from_db(product_id: int) -> dict:
    """Simula una consulta lenta a la base de datos."""
    time.sleep(0.5)
    return {"id": product_id, "name": "Teclado", "price": 49.9}


def get_product(product_id: int) -> dict:
    key = f"product:{product_id}"

    cached = r.get(key)
    if cached is not None:
        return json.loads(cached)

    product = get_product_from_db(product_id)
    r.set(key, json.dumps(product), ex=CACHE_TTL)
    return product


def update_product(product_id: int, data: dict) -> None:
    # Aquí se actualizaría la base de datos; después se invalida la caché
    r.delete(f"product:{product_id}")


if __name__ == "__main__":
    for attempt in range(1, 4):
        start = time.perf_counter()
        get_product(42)
        elapsed_ms = (time.perf_counter() - start) * 1000
        print(f"Petición {attempt}: {elapsed_ms:.1f} ms")

    update_product(42, {"price": 44.9})
    start = time.perf_counter()
    get_product(42)
    print(f"Tras invalidar: {(time.perf_counter() - start) * 1000:.1f} ms")

Ejecútalo:

python cache_demo.py

Petición 1: 503.2 ms
Petición 2: 0.4 ms
Petición 3: 0.3 ms
Tras invalidar: 501.8 ms

La primera petición es un fallo de caché y tarda lo que tarda la base de datos. Las siguientes se sirven desde Redis en menos de un milisegundo. Tras invalidar la clave, la siguiente lectura vuelve a la base de datos y repuebla la caché con el dato nuevo.

Dos decisiones que conviene tomar en cualquier aplicación real:

  • TTL: cuanto más largo, más aciertos pero más tiempo pueden servirse datos desactualizados. Invalidar la clave con delete() al escribir, como en update_product, permite usar TTL largos sin servir datos antiguos.
  • Qué cachear: resultados costosos de calcular y que se leen mucho más de lo que cambian. Cachear datos que cambian en cada petición solo añade una consulta más.

Paso 6: Medir la tasa de aciertos

La métrica más importante de una caché es su tasa de aciertos. Redis lleva la cuenta en la sección stats de INFO. Desde redis-cli, tras autenticarte:

127.0.0.1:6379> INFO stats
...
keyspace_hits:1843
keyspace_misses:212
evicted_keys:0
...

La tasa de aciertos es keyspace_hits / (keyspace_hits + keyspace_misses), en este ejemplo un 89,7%. Si es baja, revisa si los TTL son demasiado cortos o si estás cacheando datos que se leen poco. Si evicted_keys crece continuamente, maxmemory se queda corto para tu conjunto de datos activo.

Consulta el uso de memoria:

127.0.0.1:6379> INFO memory
...
used_memory_human:1.21M
maxmemory_human:256.00M
maxmemory_policy:allkeys-lru
...

Para conocer el rendimiento máximo de tu servidor, redis-benchmark lanza peticiones en paralelo. La opción -a pasa la contraseña en la línea de comandos, así que úsala solo en pruebas:

redis-benchmark -a your_strong_password -q -n 100000 -t set,get

SET: 128205.13 requests per second, p50=0.199 msec
GET: 131926.12 requests per second, p50=0.191 msec

Solución de problemas

Could not connect to Redis at 127.0.0.1:6379: Connection refused. El servicio no está en marcha, normalmente por un error en redis.conf. Revisa el motivo con sudo journalctl -u redis-server -n 30 y sudo tail /var/log/redis/redis-server.log.

OOM command not allowed when used memory > 'maxmemory'. La política de expulsión es noeviction. Comprueba que maxmemory-policy está en allkeys-lru y reinicia el servicio.

La aplicación está en otro servidor. No expongas Redis a Internet. Si ambos servidores comparten una red privada, añade la IP privada del servidor de Redis a bind (por ejemplo bind 127.0.0.1 -::1 10.0.0.5) y permite solo al servidor de la aplicación con sudo ufw allow from ip_de_la_app to any port 6379 proto tcp.

Conclusión

Tienes Redis funcionando como caché en Ubuntu 24.04 con un límite de memoria, expulsión LRU, autenticación y sin persistencia, y una aplicación que aplica el patrón cache-aside con invalidación al escribir. Como siguientes pasos, puedes guardar las sesiones de tu framework web en Redis, crear usuarios con permisos limitados mediante ACL en lugar de una única contraseña, o monitorizar keyspace_hits y evicted_keys en tu sistema de métricas.