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

Redis es conocido por su velocidad, en gran parte debido a su naturaleza en memoria. Sin embargo, cuando su conjunto de datos supera la memoria física disponible, Redis debe eliminar de forma proactiva los datos más antiguos o menos críticos para dejar espacio a nuevas entradas. Este proceso se gestiona a través de las Políticas de Desalojo (Eviction Policies), que son cruciales para mantener el rendimiento y garantizar que su caché funcione de manera óptima. Elegir la política correcta impacta directamente en las tasas de aciertos de caché, la latencia y la utilización de la memoria.

Esta guía explora las diversas políticas de desalojo integradas de Redis, explicando cómo funciona cada una y proporcionando consejos prácticos para seleccionar la estrategia más efectiva para diferentes cargas de trabajo de aplicaciones, que van desde escenarios de caché puro hasta la gestión de datos de series temporales.

---

Comprensión del Desalojo en Redis y maxmemory

Las políticas de desalojo solo entran en juego cuando el uso de memoria de Redis excede el límite establecido por la directiva de configuración maxmemory. Si maxmemory no está configurado (o está configurado a 0), Redis utilizará toda la memoria disponible y no se producirá ningún desalojo, lo que podría provocar inestabilidad del sistema si la máquina host se queda sin RAM.

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

# Establecer maxmemory en 2GB
CONFIG SET maxmemory 2gb

Una vez que la memoria está restringida, 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 Integradas de Redis

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

1. Políticas sin Requisitos de TTL

Estas políticas operan sobre todas las claves en 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 los comandos de escritura (como SET, LPUSH, etc.), devolviendo un error al cliente. Las lecturas (GET) todavía están permitidas. Esto a menudo es adecuado para datos de misión crítica donde la pérdida de datos es inaceptable, pero puede provocar errores en la aplicación bajo una alta presión de escritura.

allkeys-lru

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

allkeys-lfu

Desaloja las claves menos frecuentemente utilizadas entre todas las claves. LFU prioriza mantener las claves a las que se accede a menudo, incluso si no se ha accedido a ellas recientemente. Esto es efectivo cuando los patrones de acceso son volátiles, pero los elementos muy populares pueden permanecer residentes indefinidamente.

allkeys-random

Desaloja claves elegidas aleatoriamente hasta que se satisface el límite de memoria. Esto rara vez se recomienda para cachés de producción, a menos que el patrón de acceso a los 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 caducan al realizar el desalojo.

volatile-lru

Desaloja las claves menos recientemente utilizadas entre aquellas que tienen una expiración establecida.

volatile-lfu

Desaloja las claves menos frecuentemente utilizadas entre aquellas que tienen una expiración establecida.

volatile-random

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

volatile-ttl

Desaloja primero la clave con el tiempo de vida restante (TTL) más corto. 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.

---

Selección de la Política Correcta para su Carga de Trabajo

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

Tipo de Carga de Trabajo	Política Recomendada	Razón Fundamental
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 efectiva.
Datos Sensibles al Tiempo (p. ej., tokens, sesiones de corta duración)	volatile-ttl	Garantiza que las claves cercanas a la expiración se limpien de manera eficiente antes de que realmente expiren.
Caché de Datos Calientes (Alta asimetría de acceso)	allkeys-lfu o volatile-lfu	Protege los elementos a los que se accede con frecuencia para que no sean desalojados debido a inactividad reciente.
Retención de Datos Obligatoria (No se permite pérdida)	noeviction	Evita la pérdida de datos generando errores en las escrituras, lo que requiere intervención manual o manejo por parte de la aplicación superior.
Cargas de Trabajo Mixtas (Algunos datos caducan, otros no)	volatile-lru o volatile-ttl	Si sus claves que no caducan son esenciales, utilice una política volátil para protegerlas desalojando solo las claves que expiran explícitamente.

Ejemplo Práctico: Implementación de un Almacén de Sesiones

Si Redis se utiliza principalmente para almacenar sesiones de usuario, normalmente se establecería un TTL explícito en cada clave de sesión (p. ej., 30 minutos) y se utilizaría una política que respete los TTL. volatile-ttl es a menudo superior aquí porque si una sesión se utiliza intensamente, no debería desalojarse simplemente porque es un poco más antigua que otra sesión que no se ha tocado en semanas.

# 1. Establecer maxmemory (e.g., 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: Implementación de una Caché HTTP

Para el almacenamiento en caché de respuestas HTTP completas (que no siempre tienen un TTL establecido), se desea mantener los datos a los que se accede con más frecuencia, incluso si esos datos han permanecido sin tocar durante unas horas. allkeys-lru o allkeys-lfu son ideales.

# Usar LFU para retener objetos verdaderamente '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. Debe rastrear las siguientes métricas a través del comando INFO:

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

Mejor Práctica: Al ajustar maxmemory, deje siempre un margen de seguridad (p. 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

Las políticas de desalojo de Redis proporcionan un control detallado sobre cómo se comporta su caché bajo presión de memoria. No existe una única política 'mejor'; la elección entre desalojo basado en LRU, LFU o TTL debe alinearse precisamente con sus patrones de acceso a datos y sus requisitos comerciales. Al seleccionar cuidadosamente la política adecuada, como allkeys-lru para el almacenamiento en caché general o volatile-ttl para los almacenes de sesiones, puede maximizar la eficiencia de la caché y garantizar un rendimiento sólido para sus operaciones de datos de alta velocidad.