Caching con Redis

Visión General

El caching es la forma más útil de acelerar aplicaciones con muchas lecturas. Redis es un almacén de estructuras de datos en memoria que funciona como caché de alto rendimiento, reduciendo la carga en la base de datos y cortando tiempos de respuesta de cientos de milisegundos a microsegundos. La solucion a continuacion cubre el patrón cache-aside, gestión de TTL, serialización y estrategias de invalidación en Python, JavaScript y Java.

Cuándo Usar

Usa este recurso cuando:

• Las consultas a base de datos son lentas y devuelven los mismos resultados frecuentemente
• Necesitas reducir carga en APIs o bases de datos downstream
• Datos de sesión, perfiles de usuario o configuración necesitan acceso rápido de lectura
• Se requieren leaderboards en tiempo real, rate limiting o locks temporales

Solución

Python (redis-py)

import json
import redis
from functools import wraps

r = redis.Redis(host="localhost", port=6379, decode_responses=True)

# Helper cache-aside
def cached(key_prefix, ttl=300):
    def decorator(func):
        @wraps(func)
        def wrapper(*args, **kwargs):
            cache_key = f"{key_prefix}:{args}:{kwargs}"
            cached = r.get(cache_key)
            if cached:
                return json.loads(cached)
            result = func(*args, **kwargs)
            r.setex(cache_key, ttl, json.dumps(result))
            return result
        return wrapper
    return decorator

@cached("user_profile", ttl=600)
def get_user(user_id):
    # Consulta DB costosa
    return {"id": user_id, "name": "Alice", "orders": 42}

# Invalidación manual de caché
r.delete("user_profile:(1,):{}")

# Redis como almacén de sesiones
r.setex("session:abc123", 3600, json.dumps({"user_id": 1, "role": "admin"}))

JavaScript (ioredis)

const Redis = require("ioredis");
const redis = new Redis({ host: "localhost", port: 6379 });

async function getCached(key, fetcher, ttl = 300) {
  const cached = await redis.get(key);
  if (cached) return JSON.parse(cached);

  const data = await fetcher();
  await redis.setex(key, ttl, JSON.stringify(data));
  return data;
}

async function getUser(userId) {
  return getCached(`user:${userId}`, async () => {
    // Consulta DB costosa
    return { id: userId, name: "Alice", orders: 42 };
  }, 600);
}

// Invalidar caché
async function invalidateUser(userId) {
  await redis.del(`user:${userId}`);
}

// Redis como rate limiter
async function rateLimit(key, maxRequests = 100, window = 60) {
  const current = await redis.incr(key);
  if (current === 1) await redis.expire(key, window);
  return current <= maxRequests;
}

Java (Jedis + Spring Cache)

import redis.clients.jedis.Jedis;
import redis.clients.jedis.JedisPool;
import org.springframework.cache.annotation.Cacheable;
import org.springframework.cache.annotation.CacheEvict;
import org.springframework.stereotype.Service;

@Service
public class UserService {

    // Spring declarative caching
    @Cacheable(value = "users", key = "#userId")
    public User getUser(Long userId) {
        // Consulta DB costosa
        return new User(userId, "Alice", 42);
    }

    @CacheEvict(value = "users", key = "#userId")
    public void updateUser(Long userId, User user) {
        // Actualizar DB
    }
}

// Caching manual con Jedis
public class CacheClient {
    private final JedisPool pool = new JedisPool("localhost", 6379);

    public String get(String key) {
        try (Jedis jedis = pool.getResource()) {
            return jedis.get(key);
        }
    }

    public void setex(String key, int seconds, String value) {
        try (Jedis jedis = pool.getResource()) {
            jedis.setex(key, seconds, value);
        }
    }
}

Explicación

El patrón cache-aside (o lazy-loading) es la estrategia de caching más común:

1. Lectura: Revisa el caché primero. Si hay hit, retorna inmediatamente. Si hay miss, obtiene de la DB, guarda en caché y retorna.
2. Escritura: Actualiza la base de datos, luego invalida o actualiza el caché.
3. TTL: Cada entrada cacheada tiene un Time-To-Live. Cuando expira, la entrada es evicted y la siguiente lectura obtiene datos frescos.

Este patrón es simple, funciona con cualquier base de datos y maneja fallos de caché elegantemente: si Redis cae, la app recurre a la base de datos (degradación de caché, no outage).

Variantes

Estrategia	Cuándo Usar	Trade-off
Cache-Aside	Apps con muchas lecturas	Simple, pero caché y DB pueden divergir
Write-Through	Consistencia fuerte requerida	Escrituras más lentas, caché siempre fresco
Write-Behind	Alto throughput de escritura	Riesgo de pérdida de datos si caché crashea antes del flush
Read-Through	Lógica de invalidación compleja	La librería de caché maneja el fetching
Redis Pub/Sub	Invalidación de caché entre instancias	Sync en tiempo real, pero añade complejidad

Lo que funciona

• Configura TTL en todo: Sin TTL, tu caché crece infinitamente y datos obsoletos viven indefinidamente. Usa 5-15 minutos para datos volátiles, horas para datos de referencia estables.
• Usa versionado de cache keys: user:v2:123 permite invalidar un esquema entero cambiando el prefijo de versión.
• Serializa a JSON o MessagePack: JSON es legible; MessagePack es más pequeño y rápido. Evita pickle de Python o serialización nativa de Java por seguridad.
• Maneja cache misses elegantemente: Los fallos de caché deben degradar a la base de datos, nunca crashear la app. Usa circuit breakers para conexiones Redis.
• Monitorea hit rates: Un hit rate menor a 80% usualmente significa que tu TTL es muy corto o estás cacheando los datos equivocados.

Errores Comunes

• Cache stampede: Cuando el TTL expira, cientos de peticiones simultáneamente golpean la base de datos. Usa expiración temprana probabilística o locks para prevenir esto.
• Caché sin TTL: El crecimiento ilimitado del caché eventualmente agota la memoria. Redis evictará keys, posiblemente eliminando datos importantes.
• Almacenar objetos grandes: Serializar un blob JSON de 10MB en Redis es lento y bloquea la conexión. Cachea fragmentos más pequeños y desnormalizados.
• No invalidar en escrituras: Actualizar el email de un usuario pero no limpiar el perfil cacheado significa datos obsoletos por minutos u horas.
• Usar Redis como base de datos primaria: Redis es un almacén en memoria. Si el servidor reinicia sin persistencia (AOF/RDB), los datos se pierden. Siempre mantén la fuente primaria en una base de datos real.

Tips de Rendimiento

1. Usa PIPELINE para writes batch. Reduce round-trips de red por 10-100x:

pipe = r.pipeline(transaction=False)
for i in range(1000):
    pipe.setex(f"cache:{i}", 300, f"value:{i}")
pipe.execute()

2. Usa HSET/HGETALL para datos estructurados. Los hashes son más eficientes en memoria que keys string separadas para campos relacionados:

r.hset("user:42", mapping={"name": "Alice", "email": "alice@example.com", "role": "admin"})
user = r.hgetall("user:42")

3. Usa ZSET para datos ordenados. Los sorted sets permiten consultas eficientes de leaderboards y rankings:

r.zadd("leaderboard", {"alice": 1500, "bob": 1200, "carol": 2000})
top_10 = r.zrevrange("leaderboard", 0, 9, withscores=True)

4. Habilita lazyfree-lazy-eviction para keys grandes. Borrar keys grandes sincrónicamente bloquea Redis. Habilita lazy freeing:

# redis.conf
lazyfree-lazy-eviction yes
lazyfree-lazy-expire yes
lazyfree-lazy-server-del yes

5. Usa EXPIRE con flag NX (Redis 7+). Establece expiración solo si la key no tiene TTL:

r.expire("user:42", 3600, nx=True)  # Solo establece TTL si no existe