Redis LFU frente a LRU: ¿qué política de expulsión es la adecuada?

Las políticas LFU y LRU de Redis determinan qué claves se eliminan de la caché cuando los recursos son escasos, y por lo tanto deciden sobre Tasa de aciertos, tiempo de respuesta y consumo de memoria. Te mostraré cuándo es más adecuada la política LFU, basada en la frecuencia, o la política LRU, basada en la actualidad; cómo configurarlas y qué efectos tienen «allkeys-lfu» frente a «allkeys-lru» en el día a día; la palabra clave principal Redis LFU ocupa un lugar central en este contexto.

Puntos centrales

• Actualidad vs. Frecuencia: LRU da prioridad a los accesos más recientes, LFU da prioridad a los accesos más frecuentes.
• Aproximación En Redis: ambas políticas funcionan con muestras a través de `maxmemory-samples`.
• Cargas de trabajo Elegir: Sesiones/Cuadros de mando → LRU, Superventas/Clasificaciones → LFU.
• Sintonización Ajusta correctamente los parámetros: lfu-decay-time, maxmemory y maxmemory-samples.
• Monitoreo Es necesario: comprobar continuamente la tasa de aciertos, los desalojos por segundo y la latencia.

Cómo funciona la expulsión en Redis

Redis almacena los datos en la RAM; si el proceso llega a memoria máxima, tiene que eliminar claves. Es precisamente aquí donde entran en juego políticas como «allkeys-lru» y «allkeys-lfu», que determinan qué entradas deben ser eliminadas. Me centro en estas dos variantes porque tienen en cuenta todo el conjunto de datos, no solo las claves con TTL. Redis selecciona la clave que se va a eliminar mediante un muestreo que puedes configurar con maxmemory-samples controla; un mayor número de muestras aumenta la precisión, pero consume recursos de la CPU. Este enfoque ofrece buenos resultados en espacios de claves grandes sin que la gestión resulte demasiado costosa.

Aspectos internos: cómo implementa Redis los algoritmos LRU y LFU

Ambas políticas funcionan en Redis aproximadamente, para mantener una velocidad constante. LRU almacena una marca de tiempo por cada objeto que indica cuándo se accedió a él por última vez. En el proceso de expulsión, Redis toma una muestra y descarta al candidato „más antiguo“ de la selección. En la práctica, esto resulta extremadamente eficiente y suficientemente preciso si se elige un tamaño de muestra adecuado al espacio de claves.

Redis LFU complementa esta idea con una medición compacta de la frecuencia, que a lo largo del tiempo envejece (Decay). Cada acceso no aumenta el contador de uso de forma lineal, sino de manera atenuada, para que las fases puntuales de picos de actividad no saturen el contador de forma permanente. Al mismo tiempo, una atenuación temporal garantiza que la popularidad pasada pierda importancia con el tiempo. A través de parámetros como tiempo de decaimiento de lfu (¿a qué velocidad se acumula el historial?) y un factor de registro interno (¿en qué medida aumentan los contadores con cada acceso?), ¿cómo lo equilibras? capacidad de reacción contra Estabilidad la priorización. Regla general: valores de decaimiento más pequeños → adaptación más rápida; valores más grandes → prioridades más lentas, pero más estables.

LRU en Redis: principio, ventajas y dificultades

La LRU elimina el elemento más antiguo sin utilizar Claves y, por lo tanto, da prioridad a la actualidad. Esta lógica se adapta a patrones con localidad temporal, como sesiones, paneles en tiempo real o respuestas de API a corto plazo. Redis utiliza un LRU aproximado: las entradas llevan una marca de tiempo y las muestras seleccionan el candidato más antiguo, de forma rápida y transparente. El LRU reacciona rápidamente a los cambios, ya que las claves utilizadas recientemente permanecen en la parte superior y las más antiguas se eliminan. Pueden resultar problemáticos los escaneos únicos de gran volumen, que llenan la caché con valores efímeros y clave importantes que permanecen inactivas temporalmente. reprimir.

Consejo práctico: si utilizas LRU y realizas con frecuencia consultas masivas „en frío“ (por ejemplo, informes de back office), aísla estas cargas de trabajo en separado Cachés o planifica unos más amplios memoria máxima-Reservas. De este modo, evitarás la «contaminación de la caché», en la que se sustituyen datos valiosos que pronto volverás a necesitar.

LFU en Redis: principio, ventajas y dificultades

LFU elimina las claves con baja Frecuencia de uso y, de este modo, protege las „teclas rápidas“ a largo plazo. El contador interno crece de forma logarítmica y se va reduciendo con el tiempo (decay), para que la popularidad pasada no cuente eternamente. Esto da lugar a una ponderación equilibrada: los datos utilizados con frecuencia se conservan durante más tiempo, mientras que los valores atípicos aislados apenas alteran la prioridad. El LFU suele ofrecer una mayor tasa de aciertos en catálogos, clasificaciones o cachés de características, ya que mantiene en la memoria las claves que han demostrado su eficacia. Sin embargo, reacciona con mayor lentitud ante las nuevas tendencias, por lo que el ajuste de tiempo de decaimiento de lfu sigue siendo importante.

Para Tendencias «On/Off» (por ejemplo, campañas de marketing) se aplica lo siguiente: configura la tasa de decaimiento de tal forma que una nueva tendencia tenga un impacto perceptible, sin que el ruido momentáneo reordene constantemente la caché. En muchos proyectos, lo que da buenos resultados es: empezar de forma conservadora y luego acelerar gradualmente hasta que la tasa de aciertos se mantenga estable bajo carga.

Comparación: «recency» frente a «frequency» en la vida cotidiana

En esencia, el LRU distingue entre „cuándo se utilizó por última vez“ y el LFU, que indica „con qué frecuencia se utiliza“; yo elijo en función de los datos reales Cargas de trabajo. Para datos volátiles y cercanos al usuario, el método LRU suele resultar más natural, ya que los accesos recientes suelen anticipar los futuros. Para datos de productos o configuraciones populares, el método LFU funciona mejor, porque lo que cuenta es la popularidad duradera. En escenarios mixtos, separo las cachés por tipos de datos y aplico políticas diferentes. La siguiente tabla resume brevemente las diferencias y te ofrece una visión rápida Apoyo a la toma de decisiones.

Aspecto	LRU (allkeys-lru)	LFU (allkeys-lfu)
Prioridad	Actualidad las visitas	Frecuencia las visitas
Reacción ante un cambio de patrón	Date prisa, porque lo que cuenta es el último uso	Moderado, ya que influye el historial
Cargas de trabajo recomendadas	Sesiones, paneles de control, API en tiempo real	Éxitos de ventas, clasificaciones, cachés destacados
Sensibilidad a la „contaminación“	Bastante alto en escaneos de gran tamaño	Bastante baja, según el contador de frecuencias
Tornillos de ajuste	maxmemory-samples	tiempo de decaimiento de lfu, maxmemory-samples
Explicabilidad	Muy intuitivo	Bien, en lo que respecta a Decay

Repercusiones en el rendimiento en la práctica

En el caso de conjuntos de datos pequeños, la diferencia suele ser bajo; a medida que aumenta el tamaño, se separa el grano de la paja. El LRU convence por el bajo coste de CPU que supone la aproximación y por su causa clara: una clave se elimina porque ha sido la última en permanecer sin usar. El LFU destaca en accesos consistentes, ya que las claves «calientes» permanecen a salvo en la RAM y la tasa de aciertos aumenta de forma cuantificable. El precio que hay que pagar es la comprensión necesaria de los contadores y la decadencia, para que no reacciones ni con demasiada lentitud ni con demasiada agresividad. Compruebo los efectos mediante perfiles y métricas, en lugar de basarme solo en mi intuición para decidir.

Además, planifica el Arranque en frío 1: Tras un reinicio o una implementación, la caché está vacía o „desconoce“ las frecuencias. La estrategia LRU se estabiliza rápidamente gracias a la localidad a corto plazo. La estrategia LFU, por su propia naturaleza, necesita un cierto tiempo de calentamiento para identificar las claves realmente frecuentes. Estrategias como Precalentamiento (cargar de forma proactiva las claves importantes) o un aumento gradual del tráfico ayudan a reducir la latencia inicial y los fallos.

Configuración y ajuste: las opciones más importantes

Selecciono la política a través de política de memoria máxima, normalmente allkeys-lru o allkeys-lfu; con menos frecuencia, variantes volátiles centradas en el TTL. Con memoria máxima Establezco el límite estricto a partir del cual se inicia la expulsión y lo dimensiono en función del conjunto de datos, añadiendo un margen de seguridad. El tamaño de la muestra lo controlo mediante maxmemory-samples; los valores más altos mejoran la selección, pero consumen recursos de la CPU. Para LFU, tiempo de decaimiento de lfu Es fundamental, ya que determina la rapidez con la que las consultas antiguas pierden importancia y las nuevas cobran peso. Aquí encontrarás unas instrucciones detalladas sobre cómo dimensionar el almacenamiento: Configurar la memoria de forma óptima.

Recetas concretas para la práctica

Para empezar rápidamente, trabajo con valores predeterminados claros y realizo iteraciones bajo carga:

• allkeys-lru + maxmemory-samples 7–10 para datos volátiles y cercanos al usuario
• Redis LFU (allkeys-lfu) + lfu-decay-time conservador (por ejemplo, un valor moderado) para cargas de trabajo estables con teclas de acceso rápido

Establecer la configuración en tiempo de ejecución:

CONFIG SET maxmemory 8gb
CONFIG SET maxmemory-policy allkeys-lru
CONFIG SET maxmemory-samples 10
# Cambio a LFU:
CONFIG SET maxmemory-policy allkeys-lfu
CONFIG SET lfu-decay-time 5

En redis.conf se definen esas mismas opciones de forma permanente. Primero pruebo los cambios en el entorno de staging con una carga representativa antes de implementarlos en producción.

Seleccionar el tamaño de la muestra

maxmemory-samples Es un parámetro muy fiable: unos valores más altos mejoran la calidad de los resultados de los candidatos a ser descartados, pero consumen recursos de la CPU. Como regla general, empiezo con valores entre 7 y 10 en espacios de claves grandes y solo los reduzco cuando el tiempo de CPU escasea. En espacios de claves pequeños, a menudo bastan 5 muestras.

Seguimiento y métricas: medir en lugar de adivinar

Observo constantemente Tasa de aciertos, desalojos/s, latencias y uso de memoria, para evaluar la interacción. Si las expulsiones aumentan considerablemente, compruebo las reservas de RAM, las estrategias de TTL y la política seleccionada. Una tasa de aciertos en descenso suele indicar que los cambios en los patrones debilitan la política actual o que los conjuntos de datos no se almacenan en caché de forma suficientemente separada. Los picos de latencia a veces indican que Muestras o a una expulsión demasiado agresiva. Las pruebas de carga periódicas me ayudan a encontrar el equilibrio adecuado entre la carga de la CPU, el límite de memoria y la tasa de aciertos.

Comandos prácticos para comprobaciones rápidas:

INFO stats     # keyspace_hits, keyspace_misses, evicted_keys, expired_keys
INFO memory    # used_memory, fragmentation, allocator_overhead
LATENCY DOCTOR #: indicaciones sobre picos, p. ej., bifurcaciones o E/S

El Tasa de aciertos Lo calculo como aciertos / (aciertos + fallos). Una tasa a la baja junto con un aumento de los desahucios es una señal de alarma. llaves_desalojadas en relación con el tráfico y memoria_utilizada indica si la política debe activarse con frecuencia. Con Clave «MEMORY USAGE» identificas los objetos de gran tamaño que ocupan un espacio desproporcionado en tu caché.

Aspectos relacionados con el alojamiento y la escalabilidad: elegir la plataforma de forma consciente

Redis muestra sus puntos fuertes en un de alto rendimiento Plataforma con abundante memoria RAM, baja latencia y una conexión de red fiable. En proyectos cada vez más grandes, evito el funcionamiento continuo a plena carga, ya que entonces se activa con demasiada frecuencia la expulsión de procesos y la tasa de aciertos se ve afectada. Una buena Estrategia de alojamiento garantiza que las políticas se apliquen cuando sea necesario y no estén activas de forma permanente. A la hora de comparar, apuesto por proveedores de primera categoría como webhoster.de, cuya infraestructura soporta perfectamente cargas elevadas y permite planificar la capacidad. De este modo, la plataforma se beneficia directamente de menos expulsiones y un mejor Tiempos de respuesta y un rendimiento más constante.

Aspectos relacionados con los clústeres y las réplicas

En configuraciones de sharding (por ejemplo, Redis Cluster), las decisiones de expulsión por nodo. Es decir: el margen de seguridad, la política y el ajuste deben ser adecuados para cada nodo, no solo „de media“. Las teclas rápidas distribuidas de forma desigual entre las ranuras pueden hacer que algunos nodos alcancen el límite antes. Por lo tanto, planifica el margen de seguridad por fragmento y supervisa las expulsiones a nivel de nodo. Las réplicas heredan el estado de los datos, incluidas las claves eliminadas; en las pruebas de carga, ten en cuenta que la replicación adicional puede aumentar las latencias, sin que la política en sí sea la culpable.

Estrategias TTL y políticas mixtas

Con TTL protejo los productos de larga duración Configuraciones y doy prioridad a los datos urgentes y de corta duración. Si utilizo «volatile-lru» o «volatile-lfu», Redis solo sustituye las claves con fecha de caducidad, lo cual resulta útil cuando la caché y los valores permanentes conviven. A menudo separo las cachés por tipos de datos: sesiones en LRU, catálogos de productos en LFU, para aprovechar las ventajas de cada una. Una elección inteligente del TTL evita que las entradas obsoletas ocupen RAM innecesariamente y provoquen expulsiones. Así mantengo la memoria limpia, sin perder datos útiles Teclas de acceso rápido perder.

Importante: una política es válida por instancia. Para aplicar políticas diferentes según el tipo de datos de forma fiable, debes utilizar instancias de Redis independientes o cachés claramente delimitadas. Los espacios de nombres por sí solos no modifican la política, pero ayudan a invalidar datos de forma selectiva y a realizar mediciones.

Prueba práctica: inicio con LRU, cambio selectivo a LFU

Suelo empezar con LRU, porque es intuitivo y ofrece resultados rápidos. A continuación, identifico las cachés con teclas de acceso rápido permanentes y cambio de forma selectiva al algoritmo LFU. Este método minimiza el riesgo, ya que solo se realizan cambios allí donde los patrones de datos realmente se benefician de la lógica de frecuencia. Con «canaries» y pruebas A/B mido la tasa de aciertos y la latencia antes y después del cambio. Así optimizo paso a paso, en lugar de modificar todo el Plataforma cambiar de sistema de un solo golpe.

Una ruta de migración contrastada

• Establecer una referencia: registrar la tasa de aciertos actual, los desalojos, y los percentiles 95 y 99 de la latencia.
• Seleccionar caché piloto: zona estable, con gran volumen de lectura y teclas de acceso rápido bien definidas.
• Activar LFU, tiempo de decaimiento de lfu establecer un valor conservador, maxmemory-samples aumentar.
• Prever una fase de calentamiento y observar hasta que los valores se hayan estabilizado.
• Comparar las métricas y, solo después, realizar ajustes poco a poco.

Problemas habituales en las aplicaciones (por ejemplo, WordPress)

En los sistemas de contenido, unos TTL incorrectos y unos Claves Esto puede provocar rápidamente una avalancha de evicciones. Comprueba si las páginas dinámicas se almacenan en caché de forma involuntaria o si hay valores demasiado grandes que desbordan la memoria. Asegúrate de que la invalidación se realice correctamente tras las publicaciones, para que el contenido obsoleto desaparezca y se libere espacio. Esta guía te ayudará a identificar los errores típicos en el entorno del CMS: Error de caché de objetos. Si invalidás correctamente, estableces tiempos de vida (TTL) realistas y eliges la política adecuada, aumentarán la tasa de aciertos y Velocidad mensurable.

Otros antipatrones extraídos de la práctica:

• Grandes inmuebles individuales (por ejemplo, bloques enormes de JSON) desplazan a muchas claves pequeñas y útiles. Solución: dividir los datos y almacenar en caché solo los segmentos que realmente se utilizan.
• Estufa atronadora: Muchas fallas simultáneas en la misma clave. Solución: agrupación de solicitudes/bloqueos, pequeñas variaciones en los TTL para que las renovaciones se produzcan de forma distribuida.
• Contaminación por escáneres: Lecturas por lotes sin reutilización. Solución: instancia o espacio de nombres independiente, LRU allí con más memoria o evitar deliberadamente el almacenamiento en caché de las cargas de trabajo.
• Invalidación poco clara: Las versiones antiguas saturan la caché. Solución: esquemas de claves claros (p. ej., prefijos de versión) y rutas de invalidación deterministas.

Resumen: How I make the choice

He puesto LRU cuando la actualidad ofrece la mejor heurística para futuras consultas, como en el caso de las sesiones, los paneles de control y las API en tiempo real. Recurro a LFU, cuando existen teclas de acceso rápido claras y permanentes que también quiero proteger en momentos de picos de carga. La supervisión me indica si las expulsiones se están descontrolando o si la tasa de aciertos cae; en ese caso, ajusto las muestras, los TTL y el decaimiento. Con una elección acertada de la plataforma, un límite de memoria inteligente y cachés separadas por tipo de datos, consigo sacar siempre más partido. De este modo, la caché se mantiene rápida, predecible y adaptada al patrón de acceso, sin tener que andar a ciegas.