{"id":20962,"date":"2026-08-24T15:04:34","date_gmt":"2026-08-24T13:04:34","guid":{"rendered":"https:\/\/webhosting.de\/redis-lfu-vs-lru-eviction-policies-vergleich-cache-optimierung\/"},"modified":"2026-08-24T15:04:34","modified_gmt":"2026-08-24T13:04:34","slug":"comparaison-des-politiques-deviction-lfu-et-lru-dans-redis-optimisation-du-cache","status":"publish","type":"post","link":"https:\/\/webhosting.de\/fr\/redis-lfu-vs-lru-eviction-policies-vergleich-cache-optimierung\/","title":{"rendered":"Redis LFU vs LRU : quelle politique d'\u00e9viction choisir ?"},"content":{"rendered":"<p>Les algorithmes LFU et LRU de Redis d\u00e9terminent quelles cl\u00e9s doivent \u00eatre supprim\u00e9es du cache lorsque les ressources sont limit\u00e9es \u2013 et d\u00e9cident ainsi de <strong>Taux de r\u00e9ussite<\/strong>, temps de r\u00e9ponse et consommation de m\u00e9moire. Je vais t\u2019expliquer dans quels cas la politique LFU, ax\u00e9e sur la fr\u00e9quence, ou la politique LRU, ax\u00e9e sur l\u2019actualit\u00e9, est la plus adapt\u00e9e, comment les configurer et quels sont les effets concrets de \u00ab allkeys-lfu \u00bb par rapport \u00e0 \u00ab allkeys-lru \u00bb au quotidien ; le mot-cl\u00e9 central <strong>Redis LFU<\/strong> est au c\u0153ur de cette d\u00e9marche.<\/p>\n\n<h2>Points centraux<\/h2>\n\n<ul>\n  <li><strong>Actualit\u00e9<\/strong> vs. <strong>Fr\u00e9quence<\/strong>: LRU privil\u00e9gie les acc\u00e8s les plus r\u00e9cents, LFU privil\u00e9gie les acc\u00e8s fr\u00e9quents.<\/li>\n  <li><strong>Approximation<\/strong> Dans Redis : ces deux politiques fonctionnent avec des \u00e9chantillons d\u00e9finis par `maxmemory-samples`.<\/li>\n  <li><strong>Charges de travail<\/strong> Choisir : Sessions\/Tableaux de bord \u2192 LRU, Meilleures ventes\/Classements \u2192 LFU.<\/li>\n  <li><strong>Tuning<\/strong> R\u00e9gler correctement les param\u00e8tres suivants : lfu-decay-time, maxmemory, maxmemory-samples.<\/li>\n  <li><strong>Suivi<\/strong> N\u00e9cessaire : v\u00e9rifier en permanence le taux de r\u00e9ussite, le nombre d'expulsions par seconde et la latence.<\/li>\n<\/ul>\n\n<h2>Comment fonctionne l'\u00e9viction dans Redis<\/h2>\n\n<p>Redis stocke les donn\u00e9es en m\u00e9moire vive (RAM) ; si le processus <strong>maxmemory<\/strong>, il doit supprimer des cl\u00e9s. C'est pr\u00e9cis\u00e9ment l\u00e0 qu'interviennent des politiques telles que \u00ab allkeys-lru \u00bb et \u00ab allkeys-lfu \u00bb, qui d\u00e9terminent quelles entr\u00e9es doivent c\u00e9der la place. Je me concentre sur ces deux variantes, car elles prennent en compte l\u2019ensemble des donn\u00e9es, et pas seulement les cl\u00e9s dot\u00e9es d\u2019un TTL. Redis s\u00e9lectionne la cl\u00e9 \u00e0 supprimer \u00e0 l\u2019aide d\u2019un \u00e9chantillon que vous pouvez d\u00e9finir avec <strong>maxmemory-samples<\/strong> contr\u00f4le ; un nombre plus \u00e9lev\u00e9 d'\u00e9chantillons am\u00e9liore la pr\u00e9cision, mais sollicite davantage le processeur. Cette approche donne de bons r\u00e9sultats dans les grands espaces de cl\u00e9s, sans rendre la gestion trop co\u00fbteuse.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img fetchpriority=\"high\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/redis-eviction-policies-9472.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>En coulisses : comment Redis met en \u0153uvre les algorithmes LRU et LFU<\/h2>\n\n<p>Ces deux politiques fonctionnent dans Redis <strong>environ<\/strong>, afin de maintenir une vitesse constante. LRU enregistre, pour chaque objet, un horodatage correspondant \u00e0 son dernier acc\u00e8s. Lors d\u2019une \u00e9viction, Redis effectue un \u00e9chantillonnage et rejette le candidat \u201e le plus ancien \u201c de la s\u00e9lection. Dans la pratique, cette m\u00e9thode est extr\u00eamement efficace et suffisamment pr\u00e9cise si vous choisissez une taille d\u2019\u00e9chantillon adapt\u00e9e \u00e0 l\u2019espace de cl\u00e9s.<\/p>\n\n<p><strong>Redis LFU<\/strong> ajoute \u00e0 cette id\u00e9e une <strong>m\u00e9trique de fr\u00e9quence compacte<\/strong>, qui, au fil du temps <strong>vieillit<\/strong> (Decay). Chaque acc\u00e8s n'augmente pas le compteur d'utilisation de mani\u00e8re lin\u00e9aire, mais de fa\u00e7on att\u00e9nu\u00e9e, afin que les pics ponctuels ne saturent pas le compteur de mani\u00e8re permanente. Parall\u00e8lement, un facteur de d\u00e9croissance temporelle garantit que la popularit\u00e9 pass\u00e9e perdra \u00e0 terme de son importance. Gr\u00e2ce \u00e0 des param\u00e8tres tels que <em>lfu-temps-de-d\u00e9cay<\/em> (\u00e0 quelle vitesse l'historique vieillit-il) et un facteur de journalisation interne (dans quelle mesure les compteurs augmentent-ils \u00e0 chaque acc\u00e8s) que tu \u00e9quilibres <em>r\u00e9activit\u00e9<\/em> contre <em>Stabilit\u00e9<\/em> la hi\u00e9rarchisation. R\u00e8gle \u00e0 retenir : des valeurs de d\u00e9croissance plus faibles \u2192 ajustement plus rapide, des valeurs plus \u00e9lev\u00e9es \u2192 priorit\u00e9s plus lentes, mais plus stables.<\/p>\n\n<h2>LRU dans Redis : principe, avantages, pi\u00e8ges<\/h2>\n\n<p>La LRU supprime l'\u00e9l\u00e9ment le plus ancien <strong>inutilis\u00e9es<\/strong> Il se base sur les cl\u00e9s et privil\u00e9gie ainsi l'actualit\u00e9. Cette logique convient aux mod\u00e8les pr\u00e9sentant une localit\u00e9 temporelle, tels que les sessions, les tableaux de bord en temps r\u00e9el ou les r\u00e9ponses d'API \u00e0 court terme. Redis utilise un LRU approximatif : les entr\u00e9es sont horodat\u00e9es, et les \u00e9chantillonnages s\u00e9lectionnent le candidat le plus ancien \u2013 de mani\u00e8re rapide et tra\u00e7able. LRU r\u00e9agit rapidement aux changements, car les cl\u00e9s r\u00e9cemment utilis\u00e9es restent en haut de la liste et les plus anciennes sont \u00e9vinc\u00e9es. Les analyses ponctuelles \u00e0 grande \u00e9chelle peuvent toutefois poser probl\u00e8me, car elles remplissent le cache de valeurs \u00e9ph\u00e9m\u00e8res et font passer au second plan des cl\u00e9s importantes, mais temporairement inactives. <strong>refouler<\/strong>.<\/p>\n\n<p>Conseil pratique : si vous utilisez LRU et que vous effectuez r\u00e9guli\u00e8rement des requ\u00eates \u201e \u00e0 froid \u201c en masse (par exemple, des rapports de back-office), encapsulez ces charges de travail dans <em>distinct<\/em> Des caches, ou bien des plans plus ambitieux <strong>maxmemory<\/strong>-r\u00e9serves. Tu \u00e9vites ainsi la \u00ab pollution du cache \u00bb, qui consiste \u00e0 \u00e9vincer des donn\u00e9es pr\u00e9cieuses dont tu auras bient\u00f4t \u00e0 nouveau besoin.<\/p>\n\n<h2>LFU dans Redis : principe, avantages, pi\u00e8ges<\/h2>\n\n<p>LFU supprime les cl\u00e9s pr\u00e9sentant une faible <strong>fr\u00e9quence d'utilisation<\/strong> et pr\u00e9serve ainsi les \u201e touches de raccourci \u201c \u00e0 long terme. Le compteur interne cro\u00eet de mani\u00e8re logarithmique et s'att\u00e9nue avec le temps (Decay), afin que l'ancienne popularit\u00e9 ne p\u00e8se pas \u00e9ternellement dans le calcul. Cela conduit \u00e0 une pond\u00e9ration \u00e9quilibr\u00e9e : les donn\u00e9es fr\u00e9quemment utilis\u00e9es sont conserv\u00e9es plus longtemps, tandis que les valeurs aberrantes isol\u00e9es n\u2019influencent gu\u00e8re la priorit\u00e9. LFU offre souvent un taux de r\u00e9ussite plus \u00e9lev\u00e9 dans les catalogues, les classements ou les caches de caract\u00e9ristiques, car il conserve en m\u00e9moire les cl\u00e9s qui ont fait leurs preuves. Il r\u00e9agit toutefois plus lentement aux nouvelles tendances, c\u2019est pourquoi le r\u00e9glage de <strong>lfu-temps-de-d\u00e9cay<\/strong> reste important.<\/p>\n\n<p>Pour <strong>Tendances \u00ab On\/Off \u00bb<\/strong> (par exemple, les campagnes marketing) : r\u00e9glez le \u00ab decay \u00bb de mani\u00e8re \u00e0 ce qu'une nouvelle tendance ait un impact perceptible, sans que le bruit \u00e0 court terme ne vienne constamment r\u00e9organiser le cache. Dans de nombreux projets, la m\u00e9thode suivante a fait ses preuves : commencez prudemment, puis acc\u00e9l\u00e9rez progressivement jusqu'\u00e0 ce que le taux de r\u00e9ussite reste stable sous charge.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/redis_lfu_vs_lru_3948.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Comparaison : actualit\u00e9 vs fr\u00e9quence au quotidien<\/h2>\n\n<p>Fondamentalement, la m\u00e9thode LRU (Last Used First) distingue \u201e quand a-t-il \u00e9t\u00e9 utilis\u00e9 pour la derni\u00e8re fois \u201c et la m\u00e9thode LFU (Least Frequently Used) \u201e \u00e0 quelle fr\u00e9quence a-t-il \u00e9t\u00e9 utilis\u00e9 \u201c \u2013 je fais mon choix en fonction de la situation r\u00e9elle <strong>Charges de travail<\/strong>. Pour les donn\u00e9es volatiles et proches de l'utilisateur, l'algorithme LRU semble g\u00e9n\u00e9ralement plus naturel, car les acc\u00e8s r\u00e9cents anticipent souvent les acc\u00e8s futurs. Pour les donn\u00e9es de produits ou les configurations tr\u00e8s demand\u00e9es, l'algorithme LFU donne de meilleurs r\u00e9sultats, car c'est la popularit\u00e9 durable qui compte. Dans les sc\u00e9narios mixtes, je s\u00e9pare les caches par type de donn\u00e9es et j\u2019applique des politiques diff\u00e9rentes. Le tableau suivant r\u00e9sume bri\u00e8vement les diff\u00e9rences et te donne un aper\u00e7u rapide <strong>Aide \u00e0 la d\u00e9cision<\/strong>.<\/p>\n\n<table>\n  <thead>\n    <tr>\n      <th>Aspect<\/th>\n      <th>LRU (allkeys-lru)<\/th>\n      <th>LFU (allkeys-lfu)<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td>Priorit\u00e9<\/td>\n      <td><strong>Actualit\u00e9<\/strong> des visites<\/td>\n      <td><strong>Fr\u00e9quence<\/strong> des visites<\/td>\n    <\/tr>\n    <tr>\n      <td>R\u00e9action au changement de motif<\/td>\n      <td>Vite, c'est la derni\u00e8re utilisation qui compte<\/td>\n      <td>Mod\u00e9r\u00e9, car l'historique joue un r\u00f4le<\/td>\n    <\/tr>\n    <tr>\n      <td>Charges de travail recommand\u00e9es<\/td>\n      <td>Sessions, tableaux de bord, API en temps r\u00e9el<\/td>\n      <td>Best-sellers, classements, caches sp\u00e9ciales<\/td>\n    <\/tr>\n    <tr>\n      <td>Sensibilit\u00e9 \u00e0 la \u201e pollution \u201c<\/td>\n      <td>Plut\u00f4t \u00e9lev\u00e9 pour les scans volumineux<\/td>\n      <td>Plut\u00f4t faible en raison du compteur de fr\u00e9quence<\/td>\n    <\/tr>\n    <tr>\n      <td>Vis de r\u00e9glage<\/td>\n      <td><strong>maxmemory-samples<\/strong><\/td>\n      <td><strong>lfu-temps-de-d\u00e9cay<\/strong>, maxmemory-samples<\/td>\n    <\/tr>\n    <tr>\n      <td>explicabilit\u00e9<\/td>\n      <td>Tr\u00e8s intuitif<\/td>\n      <td>Bien, en ce qui concerne Decay<\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n\n<h2>Impact sur les performances dans la pratique<\/h2>\n\n<p>Pour les petits ensembles de donn\u00e9es, la diff\u00e9rence reste souvent <strong>faible<\/strong>; \u00e0 mesure que la taille augmente, le bon grain se s\u00e9pare de l'ivraie. LRU convainc par le faible co\u00fbt en CPU de l'approximation et par une cause claire : une cl\u00e9 est \u00e9vacu\u00e9e parce qu'elle est rest\u00e9e inutilis\u00e9e en dernier. LFU se distingue dans le cas d'acc\u00e8s r\u00e9guliers, car les cl\u00e9s \u00ab chaudes \u00bb restent en s\u00e9curit\u00e9 dans la RAM et le taux de r\u00e9ussite augmente de mani\u00e8re mesurable. Le d\u00e9fi r\u00e9side dans la compr\u00e9hension n\u00e9cessaire des compteurs et du temps de d\u00e9croissance, afin de ne pas r\u00e9agir ni trop lentement ni trop agressivement. Je v\u00e9rifie les effets \u00e0 l\u2019aide du profilage et des m\u00e9triques, plut\u00f4t que de me fier uniquement \u00e0 mon intuition. <strong>d\u00e9cider<\/strong>.<\/p>\n\n<p>Pr\u00e9vois \u00e9galement le <strong>d\u00e9marrage \u00e0 froid<\/strong> : apr\u00e8s un red\u00e9marrage ou un d\u00e9ploiement, le cache est vide ou \u201e ignore \u201c les fr\u00e9quences d'acc\u00e8s. L'algorithme LRU se stabilise rapidement gr\u00e2ce \u00e0 la localit\u00e9 \u00e0 court terme. L'algorithme LFU n\u00e9cessite naturellement un certain temps de pr\u00e9chauffage pour identifier les cl\u00e9s r\u00e9ellement fr\u00e9quemment utilis\u00e9es. Des strat\u00e9gies telles que <em>Pr\u00e9chauffage<\/em> (le chargement proactif des cl\u00e9s importantes) ou une augmentation progressive du trafic permettent d'att\u00e9nuer la latence initiale et les \u00e9checs de r\u00e9cup\u00e9ration.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/redis-eviction-policies-vergleich-4928.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Configuration et r\u00e9glages : les options essentielles<\/h2>\n\n<p>Je s\u00e9lectionne la politique via <strong>maxmemory-policy<\/strong>, g\u00e9n\u00e9ralement \u00ab allkeys-lru \u00bb ou \u00ab allkeys-lfu \u00bb, plus rarement des variantes \u00ab volatile \u00bb ax\u00e9es sur le TTL. Avec <strong>maxmemory<\/strong> Je d\u00e9finis la limite stricte \u00e0 partir de laquelle l'\u00e9viction commence, et je la dimensionne en fonction de l'ensemble de donn\u00e9es, en ajoutant une marge de s\u00e9curit\u00e9. Je contr\u00f4le la taille de l'\u00e9chantillon via <strong>maxmemory-samples<\/strong>; des valeurs plus \u00e9lev\u00e9es am\u00e9liorent la s\u00e9lection, mais sollicitent davantage le processeur. Pour LFU, <strong>lfu-temps-de-d\u00e9cay<\/strong> essentielle, car elle d\u00e9termine \u00e0 quelle vitesse les anciens acc\u00e8s perdent de leur importance et les nouveaux en gagnent. Tu trouveras ici un guide d\u00e9taill\u00e9 sur le dimensionnement de la m\u00e9moire : <a href=\"https:\/\/webhosting.de\/fr\/gestion-de-la-memoire-redis-configuration-optimale-de-la-memoire-performances-cache\/\">Configurer la m\u00e9moire de mani\u00e8re optimale<\/a>.<\/p>\n\n<h3>Des conseils concrets pour la pratique<\/h3>\n<p>Pour un d\u00e9marrage rapide, j'utilise des param\u00e8tres par d\u00e9faut bien d\u00e9finis et j'effectue des it\u00e9rations sous charge :<\/p>\n<ul>\n  <li>allkeys-lru + maxmemory-samples 7\u201310 pour les donn\u00e9es volatiles et proches de l'utilisateur<\/li>\n  <li><strong>Redis LFU<\/strong> (allkeys-lfu) + lfu-decay-time prudent (par exemple, une valeur mod\u00e9r\u00e9e) pour les charges de travail stables li\u00e9es aux raccourcis clavier<\/li>\n<\/ul>\n<p>D\u00e9finir la configuration \u00e0 l'ex\u00e9cution :<\/p>\n<pre><code>CONFIG SET maxmemory 8gb\nCONFIG SET maxmemory-policy allkeys-lru\nCONFIG SET maxmemory-samples 10\nPassage de # \u00e0 LFU :\nCONFIG SET maxmemory-policy allkeys-lfu\nCONFIG SET lfu-decay-time 5\n<\/code><\/pre>\n<p>Dans redis.conf, tu d\u00e9finis ces m\u00eames options de mani\u00e8re permanente. Je teste d'abord les modifications en environnement de pr\u00e9production avec une charge repr\u00e9sentative avant de les d\u00e9ployer en production.<\/p>\n\n<h3>Choisir la taille de l'\u00e9chantillon<\/h3>\n<p><strong>maxmemory-samples<\/strong> C'est un param\u00e8tre fiable : des valeurs plus \u00e9lev\u00e9es am\u00e9liorent la qualit\u00e9 des r\u00e9sultats pour les candidats \u00e0 l'\u00e9viction, mais consomment davantage de ressources CPU. En r\u00e8gle g\u00e9n\u00e9rale, je commence par une valeur comprise entre 7 et 10 pour les grands espaces de cl\u00e9s et je ne la r\u00e9duis que lorsque le temps CPU vient \u00e0 manquer. Pour les petits espaces de cl\u00e9s, 5 \u00e9chantillons suffisent souvent.<\/p>\n\n<h2>Suivi et indicateurs : mesurer plut\u00f4t que deviner<\/h2>\n\n<p>J'observe en permanence <strong>Taux de succ\u00e8s<\/strong>, les expulsions, les latences et l'utilisation de la m\u00e9moire, afin d'\u00e9valuer leur interaction. Si les \u00e9victions augmentent fortement, je v\u00e9rifie les r\u00e9serves de RAM, les strat\u00e9gies TTL et la politique choisie. Une baisse du taux de r\u00e9ussite indique souvent que des changements de mod\u00e8les affaiblissent la politique actuelle ou que les enregistrements ne sont pas suffisamment s\u00e9par\u00e9s dans le cache. Les pics de latence indiquent parfois que la <strong>Exemples<\/strong> ou \u00e0 une \u00e9viction trop agressive. Des tests de charge r\u00e9guliers m'aident \u00e0 trouver le bon \u00e9quilibre entre la charge du processeur, la limite de m\u00e9moire et le taux de r\u00e9ussite.<\/p>\n\n<p>Commandes pratiques pour des v\u00e9rifications rapides :<\/p>\n<pre><code>INFO stats     # keyspace_hits, keyspace_misses, evicted_keys, expired_keys\nINFO memory    # used_memory, fragmentation, allocator_overhead\nLATENCY DOCTOR # Remarques concernant les pics, par exemple le forking ou les E\/S<\/code><\/pre>\n<p>Le <strong>Taux de succ\u00e8s<\/strong> Je le calcule en divisant le nombre de \u00ab hits \u00bb par (nombre de \u00ab hits \u00bb + nombre de \u00ab misses \u00bb). Une baisse de ce taux alors que le nombre d'expulsions augmente constitue un signal d'alerte. <em>evicted_keys<\/em> par rapport au trafic et <em>used_memory<\/em> indique si la politique doit \u00eatre activ\u00e9e fr\u00e9quemment. Avec <em>Cl\u00e9 \u00ab MEMORY USAGE \u00bb<\/em> tu identifies les objets trop volumineux qui occupent une place disproportionn\u00e9e dans ta cache.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/tech_office_redis_policy_9123.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Aspects li\u00e9s \u00e0 l'h\u00e9bergement et \u00e0 l'\u00e9volutivit\u00e9 : choisir sa plateforme en toute connaissance de cause<\/h2>\n\n<p>Redis d\u00e9voile tous ses atouts sur une <strong>performant<\/strong> Une plateforme dot\u00e9e d'une m\u00e9moire vive (RAM) abondante, d'une faible latence et d'une connexion r\u00e9seau fiable. Lorsque les projets prennent de l'ampleur, j'\u00e9vite de faire tourner le syst\u00e8me en continu \u00e0 pleine charge, car cela d\u00e9clenche alors trop fr\u00e9quemment l'\u00e9viction et le taux de r\u00e9ussite en p\u00e2tit. Une bonne <a href=\"https:\/\/webhosting.de\/fr\/strategie-deviction-du-cache-dhebergement-redis\/\">Strat\u00e9gie d'h\u00e9bergement<\/a> veille \u00e0 ce que les r\u00e8gles s'appliquent lorsque cela est n\u00e9cessaire, sans fonctionner en permanence. Dans mes comparaisons, je privil\u00e9gie les fournisseurs haut de gamme tels que webhoster.de, dont l'infrastructure supporte parfaitement les charges \u00e9lev\u00e9es et permet de planifier les capacit\u00e9s. La plateforme b\u00e9n\u00e9ficie ainsi directement d'un nombre r\u00e9duit d'\u00e9victions et d'une meilleure <strong>Temps de r\u00e9ponse<\/strong> et des performances plus stables.<\/p>\n\n<h3>Aspects li\u00e9s aux clusters et aux r\u00e9pliques<\/h3>\n<p>Dans les configurations de sharding (par exemple, Redis Cluster), les d\u00e9cisions d'\u00e9viction s'appliquent <strong>par n\u0153ud<\/strong>. En d'autres termes : la marge, la politique et le r\u00e9glage doivent \u00eatre adapt\u00e9s \u00e0 chaque n\u0153ud, et pas seulement \u201e en moyenne \u201c. Les touches de raccourci r\u00e9parties de mani\u00e8re in\u00e9gale entre les slots peuvent pousser certains n\u0153uds \u00e0 leurs limites plus rapidement. Pr\u00e9voyez donc des marges par shard et surveillez les \u00e9victions au niveau des n\u0153uds. Les r\u00e9pliques reprennent l\u2019\u00e9tat des donn\u00e9es, y compris les cl\u00e9s supprim\u00e9es ; lors des tests de charge, gardez \u00e0 l\u2019esprit qu\u2019une r\u00e9plication suppl\u00e9mentaire peut augmenter les latences sans que la politique elle-m\u00eame en soit responsable.<\/p>\n\n<h2>Strat\u00e9gies TTL et politiques mixtes<\/h2>\n\n<p>Avec TTL, je prot\u00e8ge les produits durables <strong>Configurations<\/strong> et je donne la priorit\u00e9 aux donn\u00e9es sensibles au temps et \u00e0 dur\u00e9e de vie courte. Si j\u2019utilise \u00ab volatile-lru \u00bb ou \u00ab volatile-lfu \u00bb, Redis ne remplace que les cl\u00e9s dont le d\u00e9lai d\u2019expiration est \u00e9coul\u00e9 \u2013 ce qui est utile lorsque le cache et les valeurs persistantes coexistent. Je s\u00e9pare souvent les caches par type de donn\u00e9es : 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\u00e9e de vie (TTL) emp\u00eache les entr\u00e9es obsol\u00e8tes de monopoliser inutilement la m\u00e9moire vive et de provoquer des \u00e9victions. Je garde ainsi la m\u00e9moire propre, sans perdre de donn\u00e9es utiles <strong>Raccourcis clavier<\/strong> de perdre.<\/p>\n\n<p>Important : une politique s'applique <strong>par instance<\/strong>. Pour appliquer des politiques diff\u00e9rentes selon le type de donn\u00e9es, la solution la plus fiable consiste \u00e0 utiliser des instances Redis distinctes ou des caches clairement d\u00e9limit\u00e9s. Les espaces de noms ne modifient pas en eux-m\u00eames la politique ; ils facilitent toutefois l'invalidation cibl\u00e9e et le suivi.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/entwickler_schreibtisch_6354.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Test pratique : d\u00e9marrage avec LRU, passage cibl\u00e9 \u00e0 LFU<\/h2>\n\n<p>Je commence souvent par <strong>LRU<\/strong>, car cette m\u00e9thode est intuitive et donne rapidement des r\u00e9sultats. Ensuite, j'identifie les caches \u00e0 l'aide de raccourcis clavier permanents et je passe de mani\u00e8re s\u00e9lective au mode LFU. Cette approche minimise les risques, car tu n'effectues des modifications que l\u00e0 o\u00f9 les mod\u00e8les de donn\u00e9es tirent r\u00e9ellement parti de la logique de fr\u00e9quence. \u00c0 l'aide de \u00ab canaries \u00bb et de tests A\/B, je mesure le taux de r\u00e9ussite et la latence avant et apr\u00e8s la transition. Je proc\u00e8de ainsi \u00e0 une optimisation progressive, plut\u00f4t que de modifier l'ensemble du <strong>Plate-forme<\/strong> se reconvertir d'un seul coup.<\/p>\n\n<h3>Une proc\u00e9dure de migration \u00e9prouv\u00e9e<\/h3>\n<ul>\n  <li>\u00c9tablir une base de r\u00e9f\u00e9rence : enregistrer le taux de r\u00e9ussite actuel, les expulsions, ainsi que les 95e et 99e centiles de latence.<\/li>\n  <li>S\u00e9lectionner le cache pilote : zone stable, principalement d\u00e9di\u00e9e \u00e0 la lecture, avec des raccourcis clavier clairs.<\/li>\n  <li>Activer LFU, <strong>lfu-temps-de-d\u00e9cay<\/strong> opter pour une approche prudente, <strong>maxmemory-samples<\/strong> augmenter.<\/li>\n  <li>Pr\u00e9voir une phase de mise en route et surveiller jusqu'\u00e0 ce que les compteurs se soient stabilis\u00e9s.<\/li>\n  <li>Comparer les indicateurs, puis proc\u00e9der \u00e0 des ajustements progressifs.<\/li>\n<\/ul>\n\n<h2>Probl\u00e8mes courants dans les applications (par exemple, WordPress)<\/h2>\n\n<p>Dans les syst\u00e8mes de gestion de contenu, des TTL erron\u00e9s et des <strong>Cl\u00e9s<\/strong> ce qui peut rapidement entra\u00eener des vagues d'\u00e9viction. V\u00e9rifie si des pages dynamiques sont mises en cache par inadvertance ou si des valeurs trop importantes saturent la m\u00e9moire. Veillez \u00e0 ce que la mise \u00e0 jour du cache se fasse correctement apr\u00e8s les publications, afin que les contenus obsol\u00e8tes disparaissent et lib\u00e8rent de l'espace. Ce guide vous aidera \u00e0 identifier les erreurs courantes dans l'environnement CMS : <a href=\"https:\/\/webhosting.de\/fr\/erreur-de-configuration-du-cache-dobjets-redis-optimisation-des-performances-de-wordpress\/\">Erreur de cache d'objets<\/a>. Si tu invalides correctement, que tu d\u00e9finis des TTL r\u00e9alistes et que tu choisis la bonne politique, le taux de r\u00e9ussite augmente et <strong>Rapidit\u00e9<\/strong> mesurable.<\/p>\n\n<p>Autres anti-mod\u00e8les tir\u00e9s de la pratique :<\/p>\n<ul>\n  <li><strong>Grands biens immobiliers individuels<\/strong> (par exemple, d'\u00e9normes blocs JSON) prennent la place de nombreuses petites cl\u00e9s utiles. Solution : d\u00e9couper les donn\u00e9es, ne mettre en cache que les segments r\u00e9ellement utilis\u00e9s.<\/li>\n  <li><strong>Cuisini\u00e8re Thundering<\/strong>: Nombreux \u00e9checs simultan\u00e9s pour la m\u00eame cl\u00e9. Solution : regroupement des requ\u00eates\/verrouillages, l\u00e9g\u00e8res variations dans les TTL afin que les renouvellements soient r\u00e9partis dans le temps.<\/li>\n  <li><strong>Pollution par num\u00e9risation<\/strong>: Lectures par lots sans r\u00e9utilisation. Solution : instance\/espace de noms distinct, LRU avec une m\u00e9moire plus g\u00e9n\u00e9reuse, ou ne pas mettre en cache ces charges de travail de mani\u00e8re d\u00e9lib\u00e9r\u00e9e.<\/li>\n  <li><strong>Invalidation ambigu\u00eb<\/strong>: Les anciennes versions saturent le cache. Solution : des sch\u00e9mas de cl\u00e9s clairs (par exemple, des pr\u00e9fixes de version) et des chemins d'invalidation d\u00e9terministes.<\/li>\n<\/ul>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/redis-eviction-policy-7264.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>R\u00e9sum\u00e9 : Comment faire mon choix<\/h2>\n\n<p>Je mets <strong>LRU<\/strong> lorsque l'actualit\u00e9 constitue le meilleur crit\u00e8re pour les consultations futures \u2013 par exemple pour les sessions, les tableaux de bord et les API en temps r\u00e9el. J'utilise <strong>LFU<\/strong>, lorsqu\u2019il existe des raccourcis clavier clairs et permanents que je souhaite prot\u00e9ger m\u00eame en cas de pics de charge. La surveillance m\u2019indique si les \u00e9victions deviennent trop fr\u00e9quentes ou si le taux de r\u00e9ussite baisse ; je proc\u00e8de alors \u00e0 des ajustements au niveau des \u00e9chantillons, des TTL et des temps de d\u00e9croissance. Gr\u00e2ce \u00e0 un choix judicieux de la plateforme, \u00e0 une limite de m\u00e9moire bien pens\u00e9e et \u00e0 des caches distincts par type de donn\u00e9es, j\u2019obtiens constamment de meilleurs r\u00e9sultats. Ainsi, le cache reste rapide, pr\u00e9visible et adapt\u00e9 au mod\u00e8le d\u2019acc\u00e8s \u2013 sans aucune approximation.<\/p>","protected":false},"excerpt":{"rendered":"<p>Pour configurer ton cache de mani\u00e8re optimale, tu dois comprendre comment fonctionne l'\u00e9viction Redis avec les algorithmes LFU et LRU de Redis : cet article te propose une comparaison directe et t'aide \u00e0 choisir la strat\u00e9gie la plus adapt\u00e9e.<\/p>","protected":false},"author":1,"featured_media":20955,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"inline_featured_image":false,"footnotes":""},"categories":[781],"tags":[],"class_list":["post-20962","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-datenbanken-administration-anleitungen"],"acf":[],"_wp_attached_file":null,"_wp_attachment_metadata":null,"litespeed-optimize-size":null,"litespeed-optimize-set":null,"_elementor_source_image_hash":null,"_wp_attachment_image_alt":null,"stockpack_author_name":null,"stockpack_author_url":null,"stockpack_provider":null,"stockpack_image_url":null,"stockpack_license":null,"stockpack_license_url":null,"stockpack_modification":null,"color":null,"original_id":null,"original_url":null,"original_link":null,"unsplash_location":null,"unsplash_sponsor":null,"unsplash_exif":null,"unsplash_attachment_metadata":null,"_elementor_is_screenshot":null,"surfer_file_name":null,"surfer_file_original_url":null,"envato_tk_source_kit":null,"envato_tk_source_index":null,"envato_tk_manifest":null,"envato_tk_folder_name":null,"envato_tk_builder":null,"envato_elements_download_event":null,"_menu_item_type":null,"_menu_item_menu_item_parent":null,"_menu_item_object_id":null,"_menu_item_object":null,"_menu_item_target":null,"_menu_item_classes":null,"_menu_item_xfn":null,"_menu_item_url":null,"_trp_menu_languages":null,"rank_math_primary_category":null,"rank_math_title":null,"inline_featured_image":null,"_yoast_wpseo_primary_category":null,"rank_math_schema_blogposting":null,"rank_math_schema_videoobject":null,"_oembed_049c719bc4a9f89deaead66a7da9fddc":null,"_oembed_time_049c719bc4a9f89deaead66a7da9fddc":null,"_yoast_wpseo_focuskw":null,"_yoast_wpseo_linkdex":null,"_oembed_27e3473bf8bec795fbeb3a9d38489348":null,"_oembed_c3b0f6959478faf92a1f343d8f96b19e":null,"_trp_translated_slug_en_us":null,"_wp_desired_post_slug":null,"_yoast_wpseo_title":null,"tldname":null,"tldpreis":null,"tldrubrik":null,"tldpolicylink":null,"tldsize":null,"tldregistrierungsdauer":null,"tldtransfer":null,"tldwhoisprivacy":null,"tldregistrarchange":null,"tldregistrantchange":null,"tldwhoisupdate":null,"tldnameserverupdate":null,"tlddeletesofort":null,"tlddeleteexpire":null,"tldumlaute":null,"tldrestore":null,"tldsubcategory":null,"tldbildname":null,"tldbildurl":null,"tldclean":null,"tldcategory":null,"tldpolicy":null,"tldbesonderheiten":null,"tld_bedeutung":null,"_oembed_d167040d816d8f94c072940c8009f5f8":null,"_oembed_b0a0fa59ef14f8870da2c63f2027d064":null,"_oembed_4792fa4dfb2a8f09ab950a73b7f313ba":null,"_oembed_33ceb1fe54a8ab775d9410abf699878d":null,"_oembed_fd7014d14d919b45ec004937c0db9335":null,"_oembed_21a029d076783ec3e8042698c351bd7e":null,"_oembed_be5ea8a0c7b18e658f08cc571a909452":null,"_oembed_a9ca7a298b19f9b48ec5914e010294d2":null,"_oembed_f8db6b27d08a2bb1f920e7647808899a":null,"_oembed_168ebde5096e77d8a89326519af9e022":null,"_oembed_cdb76f1b345b42743edfe25481b6f98f":null,"_oembed_87b0613611ae54e86e8864265404b0a1":null,"_oembed_27aa0e5cf3f1bb4bc416a4641a5ac273":null,"_oembed_time_27aa0e5cf3f1bb4bc416a4641a5ac273":null,"_tldname":null,"_tldclean":null,"_tldpreis":null,"_tldcategory":null,"_tldsubcategory":null,"_tldpolicy":null,"_tldpolicylink":null,"_tldsize":null,"_tldregistrierungsdauer":null,"_tldtransfer":null,"_tldwhoisprivacy":null,"_tldregistrarchange":null,"_tldregistrantchange":null,"_tldwhoisupdate":null,"_tldnameserverupdate":null,"_tlddeletesofort":null,"_tlddeleteexpire":null,"_tldumlaute":null,"_tldrestore":null,"_tldbildname":null,"_tldbildurl":null,"_tld_bedeutung":null,"_tldbesonderheiten":null,"_oembed_ad96e4112edb9f8ffa35731d4098bc6b":null,"_oembed_8357e2b8a2575c74ed5978f262a10126":null,"_oembed_3d5fea5103dd0d22ec5d6a33eff7f863":null,"_eael_widget_elements":null,"_oembed_0d8a206f09633e3d62b95a15a4dd0487":null,"_oembed_time_0d8a206f09633e3d62b95a15a4dd0487":null,"_aioseo_description":null,"_eb_attr":null,"_eb_data_table":null,"_oembed_819a879e7da16dd629cfd15a97334c8a":null,"_oembed_time_819a879e7da16dd629cfd15a97334c8a":null,"_acf_changed":null,"_wpcode_auto_insert":null,"_edit_last":null,"_edit_lock":null,"_oembed_e7b913c6c84084ed9702cb4feb012ddd":null,"_oembed_bfde9e10f59a17b85fc8917fa7edf782":null,"_oembed_time_bfde9e10f59a17b85fc8917fa7edf782":null,"_oembed_03514b67990db061d7c4672de26dc514":null,"_oembed_time_03514b67990db061d7c4672de26dc514":null,"rank_math_news_sitemap_robots":null,"rank_math_robots":null,"_eael_post_view_count":"139","_trp_automatically_translated_slug_ru_ru":null,"_trp_automatically_translated_slug_et":null,"_trp_automatically_translated_slug_lv":null,"_trp_automatically_translated_slug_fr_fr":null,"_trp_automatically_translated_slug_en_us":null,"_wp_old_slug":null,"_trp_automatically_translated_slug_da_dk":null,"_trp_automatically_translated_slug_pl_pl":null,"_trp_automatically_translated_slug_es_es":null,"_trp_automatically_translated_slug_hu_hu":null,"_trp_automatically_translated_slug_fi":null,"_trp_automatically_translated_slug_ja":null,"_trp_automatically_translated_slug_lt_lt":null,"_elementor_edit_mode":null,"_elementor_template_type":null,"_elementor_version":null,"_elementor_pro_version":null,"_wp_page_template":null,"_elementor_page_settings":null,"_elementor_data":null,"_elementor_css":null,"_elementor_conditions":null,"_happyaddons_elements_cache":null,"_oembed_75446120c39305f0da0ccd147f6de9cb":null,"_oembed_time_75446120c39305f0da0ccd147f6de9cb":null,"_oembed_3efb2c3e76a18143e7207993a2a6939a":null,"_oembed_time_3efb2c3e76a18143e7207993a2a6939a":null,"_oembed_59808117857ddf57e478a31d79f76e4d":null,"_oembed_time_59808117857ddf57e478a31d79f76e4d":null,"_oembed_965c5b49aa8d22ce37dfb3bde0268600":null,"_oembed_time_965c5b49aa8d22ce37dfb3bde0268600":null,"_oembed_81002f7ee3604f645db4ebcfd1912acf":null,"_oembed_time_81002f7ee3604f645db4ebcfd1912acf":null,"_elementor_screenshot":null,"_oembed_7ea3429961cf98fa85da9747683af827":null,"_oembed_time_7ea3429961cf98fa85da9747683af827":null,"_elementor_controls_usage":null,"_elementor_page_assets":[],"_elementor_screenshot_failed":null,"theplus_transient_widgets":null,"_eael_custom_js":null,"_wp_old_date":null,"_trp_automatically_translated_slug_it_it":null,"_trp_automatically_translated_slug_pt_pt":null,"_trp_automatically_translated_slug_zh_cn":null,"_trp_automatically_translated_slug_nl_nl":null,"_trp_automatically_translated_slug_pt_br":null,"_trp_automatically_translated_slug_sv_se":null,"rank_math_analytic_object_id":null,"rank_math_internal_links_processed":"1","_trp_automatically_translated_slug_ro_ro":null,"_trp_automatically_translated_slug_sk_sk":null,"_trp_automatically_translated_slug_bg_bg":null,"_trp_automatically_translated_slug_sl_si":null,"litespeed_vpi_list":null,"litespeed_vpi_list_mobile":null,"rank_math_seo_score":null,"rank_math_contentai_score":null,"ilj_limitincominglinks":null,"ilj_maxincominglinks":null,"ilj_limitoutgoinglinks":null,"ilj_maxoutgoinglinks":null,"ilj_limitlinksperparagraph":null,"ilj_linksperparagraph":null,"ilj_blacklistdefinition":null,"ilj_linkdefinition":null,"_eb_reusable_block_ids":null,"rank_math_focus_keyword":"Redis LFU","rank_math_og_content_image":null,"_yoast_wpseo_metadesc":null,"_yoast_wpseo_content_score":null,"_yoast_wpseo_focuskeywords":null,"_yoast_wpseo_keywordsynonyms":null,"_yoast_wpseo_estimated-reading-time-minutes":null,"rank_math_description":null,"surfer_last_post_update":null,"surfer_last_post_update_direction":null,"surfer_keywords":null,"surfer_location":null,"surfer_draft_id":null,"surfer_permalink_hash":null,"surfer_scrape_ready":null,"_thumbnail_id":"20955","footnotes":null,"_links":{"self":[{"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/posts\/20962","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/comments?post=20962"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/posts\/20962\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/media\/20955"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/media?parent=20962"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/categories?post=20962"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/tags?post=20962"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}