Guía para Elegir Políticas de Desalojo Efectivas en Redis

Redis es rápido porque mantiene los datos en memoria, pero la memoria es finita. Cuando tu instancia de Redis alcanza maxmemory, la política de desalojo decide si Redis elimina claves, rechaza escrituras o solo elimina claves con un tiempo de expiración.

Elegir una política de desalojo efectiva en Redis es crucial cuando Redis actúa como caché, almacén de sesiones o almacén de datos de uso mixto. La política incorrecta puede eliminar claves importantes o hacer que las escrituras fallen durante un pico de tráfico.

---

Entendiendo el Desalojo de Redis y maxmemory

Las políticas de desalojo solo entran en juego cuando el uso de memoria de Redis supera el límite establecido por la directiva de configuración maxmemory. Si maxmemory no está configurado o está en 0, Redis no aplica un límite de memoria para escrituras normales. En un host dedicado, esto puede eventualmente llevar a presión de memoria del sistema operativo, por lo que los despliegues de caché en producción suelen establecer un límite explícito.

Para habilitar el desalojo, debes configurar maxmemory en tu archivo redis.conf o mediante el comando CONFIG SET:

# Establecer maxmemory a 2GB
CONFIG SET maxmemory 2gb

Una vez que la memoria está limitada, Redis utiliza la política de desalojo configurada para decidir qué claves descartar cuando un comando de escritura requiere más memoria.

Las Políticas de Desalojo Incorporadas de Redis

Redis ofrece varias políticas distintas. Estas se configuran mediante la directiva maxmemory-policy. Las políticas generalmente se dividen en dos categorías: las basadas en Menos Recientemente Usado (LRU) o Menos Frecuentemente Usado (LFU), y aquellas dirigidas a claves con Tiempo de Vida (TTL) establecido.

1. Políticas Sin Requisitos de TTL

Estas políticas operan en todas las claves de la base de datos, independientemente de si tienen un tiempo de expiración establecido.

noeviction

Esta es la política predeterminada. Cuando se alcanza el límite de memoria, Redis rechaza comandos de escritura (como SET, LPUSH, etc.), devolviendo un error al cliente. Las lecturas (GET) aún están permitidas. Esto suele ser adecuado para datos críticos donde la pérdida de datos es inaceptable, pero puede provocar errores en la aplicación bajo alta presión de escritura.

allkeys-lru

Elimina las claves menos recientemente usadas entre todas las claves en la base de datos hasta que el uso de memoria esté por debajo del límite de maxmemory. Esta es la opción estándar para un caché de propósito general donde todos los elementos de datos son igualmente almacenables en caché.

allkeys-lfu

Elimina las claves menos frecuentemente usadas entre todas las claves. LFU prioriza mantener las claves que se acceden con frecuencia, incluso si no se han accedido recientemente. Esto es efectivo cuando los patrones de acceso son volátiles, pero los elementos muy populares podrían permanecer residentes indefinidamente.

allkeys-random

Elimina claves elegidas aleatoriamente hasta que se cumpla el límite de memoria. Rara vez se recomienda para cachés de producción a menos que el patrón de acceso a datos sea completamente uniforme e impredecible.

2. Políticas que Requieren TTL (Claves Volátiles)

Estas políticas solo consideran claves que tienen un tiempo de expiración explícito (EXPIRE o SETEX) establecido. Ignoran las claves que no expiran al realizar el desalojo.

volatile-lru

Elimina las claves menos recientemente usadas entre aquellas que tienen una expiración establecida.

volatile-lfu

Elimina las claves menos frecuentemente usadas entre aquellas que tienen una expiración establecida.

volatile-random

Elimina una clave aleatoria entre aquellas que tienen una expiración establecida.

volatile-ttl

Elimina primero la clave con el tiempo de vida restante más corto (TTL). Esto es ideal para datos sensibles al tiempo, como tokens de sesión o estado temporal de la aplicación, asegurando que los datos más antiguos y próximos a expirar se limpien primero.

---

Seleccionando la Política Correcta para tu Carga de Trabajo

La política de desalojo óptima depende completamente de qué estás almacenando en caché y cómo tu aplicación utiliza los datos.

Tipo de Carga de Trabajo	Política Recomendada	Razón
Caché de Propósito General (Más común)	allkeys-lru	Asume que los datos más antiguos y no utilizados deben eliminarse primero, independientemente del TTL. Simple y altamente efectivo.
Datos Sensibles al Tiempo (ej., tokens, sesiones de corta duración)	volatile-ttl	Elimina preferentemente las claves con el TTL restante más corto.
Caché de Datos Calientes (Alta asimetría de acceso)	allkeys-lfu o volatile-lfu	Protege los elementos accedidos frecuentemente de ser eliminados debido a inactividad reciente.
Retención Obligatoria de Datos (Sin pérdida permitida)	noeviction	Previene la pérdida de datos al generar errores en las escrituras, requiriendo intervención manual o manejo por parte de la aplicación upstream.
Cargas de Trabajo Mixtas (Algunos datos expiran, otros no)	volatile-lru, volatile-lfu o volatile-ttl	Si tus claves que no expiran son esenciales, usa una política volátil para protegerlas eliminando solo las claves que expiran explícitamente.

Ejemplo Práctico: Implementando un Almacén de Sesiones

Si Redis se usa principalmente para almacenar sesiones de usuario, establece un TTL explícito en cada clave de sesión, por ejemplo, 30 minutos. volatile-ttl puede funcionar cuando el tiempo de vida restante es la señal más importante. Si tu aplicación renueva los TTL de las sesiones con la actividad, las sesiones activas mantienen naturalmente un TTL restante más largo. Si no renueva los TTL, considera volatile-lru o volatile-lfu en su lugar.

# 1. Establecer maxmemory (ej., 10GB)
CONFIG SET maxmemory 10gb

# 2. Elegir la política dirigida a datos con tiempo de vida
CONFIG SET maxmemory-policy volatile-ttl

Ejemplo Práctico: Implementando un Caché HTTP

Para almacenar en caché respuestas HTTP completas (que podrían no tener siempre un TTL establecido), quieres mantener los datos que se acceden con más frecuencia, incluso si esos datos han estado sin tocarse durante unas horas. allkeys-lru o allkeys-lfu son ideales.

# Usar LFU para retener objetos realmente 'calientes', independientemente de su tiempo de creación
CONFIG SET maxmemory-policy allkeys-lfu

Monitoreo y Ajuste

Después de seleccionar una política, el monitoreo continuo es esencial. Debes rastrear las siguientes métricas mediante el comando INFO:

• used_memory: Qué tan cerca estás del límite de maxmemory.
• evicted_keys: La tasa a la que Redis está descartando datos. Una tasa de desalojo constantemente alta indica que tu configuración de maxmemory es demasiado baja para tu carga de trabajo, o tu política de desalojo es demasiado agresiva.
• Tasa de Aciertos de Caché de la Aplicación: La medida definitiva de éxito. Si tu tasa de aciertos disminuye cuando aumenta la presión de memoria, tu selección de política o el límite de maxmemory necesita ajuste.

Mejor Práctica: Al ajustar maxmemory, siempre deja un margen de seguridad (ej., 10-20% de memoria libre) para tener en cuenta el buffering de replicación, el buffering de comandos y la posible sobrecarga de las estructuras de datos internas de Redis.

Conclusión Final

Comienza con allkeys-lru para un caché general, allkeys-lfu cuando un pequeño conjunto de claves calientes domina el tráfico, y una política volatile-* solo cuando las claves que no expiran deben ser protegidas. Luego observa evicted_keys, la tasa de aciertos de la aplicación y los errores de escritura bajo carga antes de dar por terminada la política.