Redis LFU vs LRU : quelle politique d'éviction choisir ?

Les algorithmes LFU et LRU de Redis déterminent quelles clés doivent être supprimées du cache lorsque les ressources sont limitées – et décident ainsi de Taux de réussite, temps de réponse et consommation de mémoire. Je vais t’expliquer dans quels cas la politique LFU, axée sur la fréquence, ou la politique LRU, axée sur l’actualité, est la plus adaptée, comment les configurer et quels sont les effets concrets de « allkeys-lfu » par rapport à « allkeys-lru » au quotidien ; le mot-clé central Redis LFU est au cœur de cette démarche.

Points centraux

• Actualité vs. Fréquence: LRU privilégie les accès les plus récents, LFU privilégie les accès fréquents.
• Approximation Dans Redis : ces deux politiques fonctionnent avec des échantillons définis par `maxmemory-samples`.
• Charges de travail Choisir : Sessions/Tableaux de bord → LRU, Meilleures ventes/Classements → LFU.
• Tuning Régler correctement les paramètres suivants : lfu-decay-time, maxmemory, maxmemory-samples.
• Suivi Nécessaire : vérifier en permanence le taux de réussite, le nombre d'expulsions par seconde et la latence.

Comment fonctionne l'éviction dans Redis

Redis stocke les données en mémoire vive (RAM) ; si le processus maxmemory, il doit supprimer des clés. C'est précisément là qu'interviennent des politiques telles que « allkeys-lru » et « allkeys-lfu », qui déterminent quelles entrées doivent céder la place. Je me concentre sur ces deux variantes, car elles prennent en compte l’ensemble des données, et pas seulement les clés dotées d’un TTL. Redis sélectionne la clé à supprimer à l’aide d’un échantillon que vous pouvez définir avec maxmemory-samples contrôle ; un nombre plus élevé d'échantillons améliore la précision, mais sollicite davantage le processeur. Cette approche donne de bons résultats dans les grands espaces de clés, sans rendre la gestion trop coûteuse.

En coulisses : comment Redis met en œuvre les algorithmes LRU et LFU

Ces deux politiques fonctionnent dans Redis environ, afin de maintenir une vitesse constante. LRU enregistre, pour chaque objet, un horodatage correspondant à son dernier accès. Lors d’une éviction, Redis effectue un échantillonnage et rejette le candidat „ le plus ancien “ de la sélection. Dans la pratique, cette méthode est extrêmement efficace et suffisamment précise si vous choisissez une taille d’échantillon adaptée à l’espace de clés.

Redis LFU ajoute à cette idée une métrique de fréquence compacte, qui, au fil du temps vieillit (Decay). Chaque accès n'augmente pas le compteur d'utilisation de manière linéaire, mais de façon atténuée, afin que les pics ponctuels ne saturent pas le compteur de manière permanente. Parallèlement, un facteur de décroissance temporelle garantit que la popularité passée perdra à terme de son importance. Grâce à des paramètres tels que lfu-temps-de-décay (à quelle vitesse l'historique vieillit-il) et un facteur de journalisation interne (dans quelle mesure les compteurs augmentent-ils à chaque accès) que tu équilibres réactivité contre Stabilité la hiérarchisation. Règle à retenir : des valeurs de décroissance plus faibles → ajustement plus rapide, des valeurs plus élevées → priorités plus lentes, mais plus stables.

LRU dans Redis : principe, avantages, pièges

La LRU supprime l'élément le plus ancien inutilisées Il se base sur les clés et privilégie ainsi l'actualité. Cette logique convient aux modèles présentant une localité temporelle, tels que les sessions, les tableaux de bord en temps réel ou les réponses d'API à court terme. Redis utilise un LRU approximatif : les entrées sont horodatées, et les échantillonnages sélectionnent le candidat le plus ancien – de manière rapide et traçable. LRU réagit rapidement aux changements, car les clés récemment utilisées restent en haut de la liste et les plus anciennes sont évincées. Les analyses ponctuelles à grande échelle peuvent toutefois poser problème, car elles remplissent le cache de valeurs éphémères et font passer au second plan des clés importantes, mais temporairement inactives. refouler.

Conseil pratique : si vous utilisez LRU et que vous effectuez régulièrement des requêtes „ à froid “ en masse (par exemple, des rapports de back-office), encapsulez ces charges de travail dans distinct Des caches, ou bien des plans plus ambitieux maxmemory-réserves. Tu évites ainsi la « pollution du cache », qui consiste à évincer des données précieuses dont tu auras bientôt à nouveau besoin.

LFU dans Redis : principe, avantages, pièges

LFU supprime les clés présentant une faible fréquence d'utilisation et préserve ainsi les „ touches de raccourci “ à long terme. Le compteur interne croît de manière logarithmique et s'atténue avec le temps (Decay), afin que l'ancienne popularité ne pèse pas éternellement dans le calcul. Cela conduit à une pondération équilibrée : les données fréquemment utilisées sont conservées plus longtemps, tandis que les valeurs aberrantes isolées n’influencent guère la priorité. LFU offre souvent un taux de réussite plus élevé dans les catalogues, les classements ou les caches de caractéristiques, car il conserve en mémoire les clés qui ont fait leurs preuves. Il réagit toutefois plus lentement aux nouvelles tendances, c’est pourquoi le réglage de lfu-temps-de-décay reste important.

Pour Tendances « On/Off » (par exemple, les campagnes marketing) : réglez le « decay » de manière à ce qu'une nouvelle tendance ait un impact perceptible, sans que le bruit à court terme ne vienne constamment réorganiser le cache. Dans de nombreux projets, la méthode suivante a fait ses preuves : commencez prudemment, puis accélérez progressivement jusqu'à ce que le taux de réussite reste stable sous charge.

Comparaison : actualité vs fréquence au quotidien

Fondamentalement, la méthode LRU (Last Used First) distingue „ quand a-t-il été utilisé pour la dernière fois “ et la méthode LFU (Least Frequently Used) „ à quelle fréquence a-t-il été utilisé “ – je fais mon choix en fonction de la situation réelle Charges de travail. Pour les données volatiles et proches de l'utilisateur, l'algorithme LRU semble généralement plus naturel, car les accès récents anticipent souvent les accès futurs. Pour les données de produits ou les configurations très demandées, l'algorithme LFU donne de meilleurs résultats, car c'est la popularité durable qui compte. Dans les scénarios mixtes, je sépare les caches par type de données et j’applique des politiques différentes. Le tableau suivant résume brièvement les différences et te donne un aperçu rapide Aide à la décision.

Aspect	LRU (allkeys-lru)	LFU (allkeys-lfu)
Priorité	Actualité des visites	Fréquence des visites
Réaction au changement de motif	Vite, c'est la dernière utilisation qui compte	Modéré, car l'historique joue un rôle
Charges de travail recommandées	Sessions, tableaux de bord, API en temps réel	Best-sellers, classements, caches spéciales
Sensibilité à la „ pollution “	Plutôt élevé pour les scans volumineux	Plutôt faible en raison du compteur de fréquence
Vis de réglage	maxmemory-samples	lfu-temps-de-décay, maxmemory-samples
explicabilité	Très intuitif	Bien, en ce qui concerne Decay

Impact sur les performances dans la pratique

Pour les petits ensembles de données, la différence reste souvent faible; à mesure que la taille augmente, le bon grain se sépare de l'ivraie. LRU convainc par le faible coût en CPU de l'approximation et par une cause claire : une clé est évacuée parce qu'elle est restée inutilisée en dernier. LFU se distingue dans le cas d'accès réguliers, car les clés « chaudes » restent en sécurité dans la RAM et le taux de réussite augmente de manière mesurable. Le défi réside dans la compréhension nécessaire des compteurs et du temps de décroissance, afin de ne pas réagir ni trop lentement ni trop agressivement. Je vérifie les effets à l’aide du profilage et des métriques, plutôt que de me fier uniquement à mon intuition. décider.

Prévois également le démarrage à froid : après un redémarrage ou un déploiement, le cache est vide ou „ ignore “ les fréquences d'accès. L'algorithme LRU se stabilise rapidement grâce à la localité à court terme. L'algorithme LFU nécessite naturellement un certain temps de préchauffage pour identifier les clés réellement fréquemment utilisées. Des stratégies telles que Préchauffage (le chargement proactif des clés importantes) ou une augmentation progressive du trafic permettent d'atténuer la latence initiale et les échecs de récupération.

Configuration et réglages : les options essentielles

Je sélectionne la politique via maxmemory-policy, généralement « allkeys-lru » ou « allkeys-lfu », plus rarement des variantes « volatile » axées sur le TTL. Avec maxmemory Je définis la limite stricte à partir de laquelle l'éviction commence, et je la dimensionne en fonction de l'ensemble de données, en ajoutant une marge de sécurité. Je contrôle la taille de l'échantillon via maxmemory-samples; des valeurs plus élevées améliorent la sélection, mais sollicitent davantage le processeur. Pour LFU, lfu-temps-de-décay essentielle, car elle détermine à quelle vitesse les anciens accès perdent de leur importance et les nouveaux en gagnent. Tu trouveras ici un guide détaillé sur le dimensionnement de la mémoire : Configurer la mémoire de manière optimale.

Des conseils concrets pour la pratique

Pour un démarrage rapide, j'utilise des paramètres par défaut bien définis et j'effectue des itérations sous charge :

• allkeys-lru + maxmemory-samples 7–10 pour les données volatiles et proches de l'utilisateur
• Redis LFU (allkeys-lfu) + lfu-decay-time prudent (par exemple, une valeur modérée) pour les charges de travail stables liées aux raccourcis clavier

Définir la configuration à l'exécution :

CONFIG SET maxmemory 8gb
CONFIG SET maxmemory-policy allkeys-lru
CONFIG SET maxmemory-samples 10
Passage de # à LFU :
CONFIG SET maxmemory-policy allkeys-lfu
CONFIG SET lfu-decay-time 5

Dans redis.conf, tu définis ces mêmes options de manière permanente. Je teste d'abord les modifications en environnement de préproduction avec une charge représentative avant de les déployer en production.

Choisir la taille de l'échantillon

maxmemory-samples C'est un paramètre fiable : des valeurs plus élevées améliorent la qualité des résultats pour les candidats à l'éviction, mais consomment davantage de ressources CPU. En règle générale, je commence par une valeur comprise entre 7 et 10 pour les grands espaces de clés et je ne la réduis que lorsque le temps CPU vient à manquer. Pour les petits espaces de clés, 5 échantillons suffisent souvent.

Suivi et indicateurs : mesurer plutôt que deviner

J'observe en permanence Taux de succès, les expulsions, les latences et l'utilisation de la mémoire, afin d'évaluer leur interaction. Si les évictions augmentent fortement, je vérifie les réserves de RAM, les stratégies TTL et la politique choisie. Une baisse du taux de réussite indique souvent que des changements de modèles affaiblissent la politique actuelle ou que les enregistrements ne sont pas suffisamment séparés dans le cache. Les pics de latence indiquent parfois que la Exemples ou à une éviction trop agressive. Des tests de charge réguliers m'aident à trouver le bon équilibre entre la charge du processeur, la limite de mémoire et le taux de réussite.

Commandes pratiques pour des vérifications rapides :

INFO stats     # keyspace_hits, keyspace_misses, evicted_keys, expired_keys
INFO memory    # used_memory, fragmentation, allocator_overhead
LATENCY DOCTOR # Remarques concernant les pics, par exemple le forking ou les E/S

Le Taux de succès Je le calcule en divisant le nombre de « hits » par (nombre de « hits » + nombre de « misses »). Une baisse de ce taux alors que le nombre d'expulsions augmente constitue un signal d'alerte. evicted_keys par rapport au trafic et used_memory indique si la politique doit être activée fréquemment. Avec Clé « MEMORY USAGE » tu identifies les objets trop volumineux qui occupent une place disproportionnée dans ta cache.

Aspects liés à l'hébergement et à l'évolutivité : choisir sa plateforme en toute connaissance de cause

Redis dévoile tous ses atouts sur une performant Une plateforme dotée d'une mémoire vive (RAM) abondante, d'une faible latence et d'une connexion réseau fiable. Lorsque les projets prennent de l'ampleur, j'évite de faire tourner le système en continu à pleine charge, car cela déclenche alors trop fréquemment l'éviction et le taux de réussite en pâtit. Une bonne Stratégie d'hébergement veille à ce que les règles s'appliquent lorsque cela est nécessaire, sans fonctionner en permanence. Dans mes comparaisons, je privilégie les fournisseurs haut de gamme tels que webhoster.de, dont l'infrastructure supporte parfaitement les charges élevées et permet de planifier les capacités. La plateforme bénéficie ainsi directement d'un nombre réduit d'évictions et d'une meilleure Temps de réponse et des performances plus stables.

Aspects liés aux clusters et aux répliques

Dans les configurations de sharding (par exemple, Redis Cluster), les décisions d'éviction s'appliquent par nœud. En d'autres termes : la marge, la politique et le réglage doivent être adaptés à chaque nœud, et pas seulement „ en moyenne “. Les touches de raccourci réparties de manière inégale entre les slots peuvent pousser certains nœuds à leurs limites plus rapidement. Prévoyez donc des marges par shard et surveillez les évictions au niveau des nœuds. Les répliques reprennent l’état des données, y compris les clés supprimées ; lors des tests de charge, gardez à l’esprit qu’une réplication supplémentaire peut augmenter les latences sans que la politique elle-même en soit responsable.

Stratégies TTL et politiques mixtes

Avec TTL, je protège les produits durables Configurations et je donne la priorité aux données sensibles au temps et à durée de vie courte. Si j’utilise « volatile-lru » ou « volatile-lfu », Redis ne remplace que les clés dont le délai d’expiration est écoulé – ce qui est utile lorsque le cache et les valeurs persistantes coexistent. Je sépare souvent les caches par type de données : les sessions en LRU, les catalogues de produits en LFU, afin de tirer parti des atouts respectifs de chaque algorithme. Un choix judicieux de la durée de vie (TTL) empêche les entrées obsolètes de monopoliser inutilement la mémoire vive et de provoquer des évictions. Je garde ainsi la mémoire propre, sans perdre de données utiles Raccourcis clavier de perdre.

Important : une politique s'applique par instance. Pour appliquer des politiques différentes selon le type de données, la solution la plus fiable consiste à utiliser des instances Redis distinctes ou des caches clairement délimités. Les espaces de noms ne modifient pas en eux-mêmes la politique ; ils facilitent toutefois l'invalidation ciblée et le suivi.

Test pratique : démarrage avec LRU, passage ciblé à LFU

Je commence souvent par LRU, car cette méthode est intuitive et donne rapidement des résultats. Ensuite, j'identifie les caches à l'aide de raccourcis clavier permanents et je passe de manière sélective au mode LFU. Cette approche minimise les risques, car tu n'effectues des modifications que là où les modèles de données tirent réellement parti de la logique de fréquence. À l'aide de « canaries » et de tests A/B, je mesure le taux de réussite et la latence avant et après la transition. Je procède ainsi à une optimisation progressive, plutôt que de modifier l'ensemble du Plate-forme se reconvertir d'un seul coup.

Une procédure de migration éprouvée

• Établir une base de référence : enregistrer le taux de réussite actuel, les expulsions, ainsi que les 95e et 99e centiles de latence.
• Sélectionner le cache pilote : zone stable, principalement dédiée à la lecture, avec des raccourcis clavier clairs.
• Activer LFU, lfu-temps-de-décay opter pour une approche prudente, maxmemory-samples augmenter.
• Prévoir une phase de mise en route et surveiller jusqu'à ce que les compteurs se soient stabilisés.
• Comparer les indicateurs, puis procéder à des ajustements progressifs.

Problèmes courants dans les applications (par exemple, WordPress)

Dans les systèmes de gestion de contenu, des TTL erronés et des Clés ce qui peut rapidement entraîner des vagues d'éviction. Vérifie si des pages dynamiques sont mises en cache par inadvertance ou si des valeurs trop importantes saturent la mémoire. Veillez à ce que la mise à jour du cache se fasse correctement après les publications, afin que les contenus obsolètes disparaissent et libèrent de l'espace. Ce guide vous aidera à identifier les erreurs courantes dans l'environnement CMS : Erreur de cache d'objets. Si tu invalides correctement, que tu définis des TTL réalistes et que tu choisis la bonne politique, le taux de réussite augmente et Rapidité mesurable.

Autres anti-modèles tirés de la pratique :

• Grands biens immobiliers individuels (par exemple, d'énormes blocs JSON) prennent la place de nombreuses petites clés utiles. Solution : découper les données, ne mettre en cache que les segments réellement utilisés.
• Cuisinière Thundering: Nombreux échecs simultanés pour la même clé. Solution : regroupement des requêtes/verrouillages, légères variations dans les TTL afin que les renouvellements soient répartis dans le temps.
• Pollution par numérisation: Lectures par lots sans réutilisation. Solution : instance/espace de noms distinct, LRU avec une mémoire plus généreuse, ou ne pas mettre en cache ces charges de travail de manière délibérée.
• Invalidation ambiguë: Les anciennes versions saturent le cache. Solution : des schémas de clés clairs (par exemple, des préfixes de version) et des chemins d'invalidation déterministes.

Résumé : Comment faire mon choix

Je mets LRU lorsque l'actualité constitue le meilleur critère pour les consultations futures – par exemple pour les sessions, les tableaux de bord et les API en temps réel. J'utilise LFU, lorsqu’il existe des raccourcis clavier clairs et permanents que je souhaite protéger même en cas de pics de charge. La surveillance m’indique si les évictions deviennent trop fréquentes ou si le taux de réussite baisse ; je procède alors à des ajustements au niveau des échantillons, des TTL et des temps de décroissance. Grâce à un choix judicieux de la plateforme, à une limite de mémoire bien pensée et à des caches distincts par type de données, j’obtiens constamment de meilleurs résultats. Ainsi, le cache reste rapide, prévisible et adapté au modèle d’accès – sans aucune approximation.