Guide pour choisir des politiques d'éviction Redis efficaces

Redis est réputé pour sa rapidité, en grande partie grâce à sa nature en mémoire. Cependant, lorsque votre ensemble de données devient plus volumineux que la mémoire physique disponible, Redis doit supprimer de manière proactive les données les plus anciennes ou les moins critiques pour faire de la place aux nouvelles entrées. Ce processus est géré par les Politiques d'Éviction, cruciales pour maintenir les performances et garantir que votre cache fonctionne de manière optimale. Le choix de la politique correcte impacte directement les taux de succès du cache, la latence et l'utilisation de la mémoire.

Ce guide explore les différentes politiques d'éviction intégrées à Redis, expliquant le fonctionnement de chacune et fournissant des conseils pratiques pour sélectionner la stratégie la plus efficace pour diverses charges de travail d'application, allant des scénarios de mise en cache pure à la gestion des données de séries chronologiques (time-series).

---

Comprendre l'éviction Redis et maxmemory

Les politiques d'éviction n'entrent en jeu que lorsque l'utilisation de la mémoire de Redis dépasse la limite définie par la directive de configuration maxmemory. Si maxmemory n'est pas défini (ou est défini à 0), Redis utilisera toute la mémoire disponible et aucune éviction ne se produira, ce qui pourrait entraîner une instabilité du système si la machine hôte manque de RAM.

Pour activer l'éviction, vous devez configurer maxmemory dans votre fichier redis.conf ou via la commande CONFIG SET :

# Définir maxmemory à 2 Go
CONFIG SET maxmemory 2gb

Une fois la mémoire contrainte, Redis utilise la politique d'éviction configurée pour décider quelles clés supprimer lorsqu'une commande d'écriture nécessite plus de mémoire.

Les politiques d'éviction intégrées à Redis

Redis propose plusieurs politiques distinctes. Celles-ci sont configurées à l'aide de la directive maxmemory-policy. Les politiques se répartissent généralement en deux catégories : celles basées sur le Moins Récemment Utilisé (LRU) ou le Moins Fréquemment Utilisé (LFU), et celles ciblant les clés ayant un Temps de Vie (TTL) défini.

1. Politiques sans exigences de TTL

Ces politiques s'appliquent à toutes les clés de la base de données, qu'elles aient ou non une heure d'expiration définie.

noeviction

C'est la politique par défaut. Lorsque la limite de mémoire est atteinte, Redis rejette les commandes d'écriture (telles que SET, LPUSH, etc.), renvoyant une erreur au client. Les lectures (GET) sont toujours autorisées. Ceci convient souvent aux données critiques où la perte de données est inacceptable, mais cela peut entraîner des erreurs d'application sous une forte pression d'écriture.

allkeys-lru

Évacue les clés les moins récemment utilisées parmi toutes les clés de la base de données jusqu'à ce que l'utilisation de la mémoire soit inférieure à la limite maxmemory. C'est le choix standard pour un cache à usage général où tous les éléments de données sont également susceptibles d'être mis en cache.

allkeys-lfu

Évacue les clés les moins fréquemment utilisées parmi toutes les clés. LFU privilégie la conservation des clés qui sont souvent accédées, même si elles n'ont pas été consultées récemment. Ceci est efficace lorsque les modèles d'accès sont volatils, mais les éléments très populaires pourraient rester résidents indéfiniment.

allkeys-random

Évacue des clés choisies au hasard jusqu'à ce que la limite de mémoire soit satisfaite. Ceci est rarement recommandé pour les caches de production, à moins que le modèle d'accès aux données ne soit complètement uniforme et imprévisible.

2. Politiques nécessitant un TTL (Clés Volatiles)

Ces politiques ne considèrent que les clés ayant une heure d'expiration explicite (EXPIRE ou SETEX) définie. Elles ignorent les clés sans expiration lors de l'éviction.

volatile-lru

Évacue les clés les moins récemment utilisées parmi celles ayant une expiration définie.

volatile-lfu

Évacue les clés les moins fréquemment utilisées parmi celles ayant une expiration définie.

volatile-random

Évacue une clé aléatoire parmi celles ayant une expiration définie.

volatile-ttl

Évacue en priorité la clé ayant le temps de vie restant (TTL) le plus court. Ceci est idéal pour les données sensibles au temps, telles que les jetons de session ou l'état temporaire de l'application, garantissant que les données plus anciennes et bientôt expirées sont nettoyées en premier.

---

Sélectionner la bonne politique pour votre charge de travail

La politique d'éviction optimale dépend entièrement de ce que vous mettez en cache et de la façon dont votre application utilise les données.

Type de Charge de Travail	Politique Recommandée	Justification
Cache à Usage Général (Le plus courant)	allkeys-lru	Suppose que les données plus anciennes et inutilisées doivent être supprimées en premier, quel que soit le TTL. Simple et très efficace.
Données Sensibles au Temps (ex: jetons, sessions de courte durée)	volatile-ttl	Garantit que les clés approchant de l'expiration sont nettoyées efficacement avant d'expirer réellement.
Cache de Données « Chaudes » (Forte disparité d'accès)	allkeys-lfu ou volatile-lfu	Protège les éléments fréquemment consultés contre l'éviction due à une inactivité récente.
Rétention de Données Obligatoire (Aucune perte autorisée)	noeviction	Empêche la perte de données en générant des erreurs lors des écritures, nécessitant une intervention manuelle ou une gestion par l'application en amont.
Charges de Travail Mixtes (Certaines données expirent, d'autres non)	volatile-lru ou volatile-ttl	Si vos clés non expirantes sont essentielles, utilisez une politique volatile pour les protéger en n'évacuant que les clés explicitement expirantes.

Exemple Pratique : Implémentation d'un magasin de sessions

Si Redis est principalement utilisé pour stocker des sessions utilisateur, vous définiriez généralement un TTL explicite sur chaque clé de session (par exemple, 30 minutes) et utiliseriez une politique qui respecte les TTL. volatile-ttl est souvent supérieur ici car si une session est très utilisée, elle ne devrait pas être évacuée simplement parce qu'elle est légèrement plus ancienne qu'une autre session qui n'a pas été touchée depuis des semaines.

# 1. Définir maxmemory (par exemple, 10 Go)
CONFIG SET maxmemory 10gb

# 2. Choisir la politique ciblant les données ayant une durée de vie
CONFIG SET maxmemory-policy volatile-ttl

Exemple Pratique : Implémentation d'un Cache HTTP

Pour mettre en cache des réponses HTTP complètes (qui n'ont pas toujours de TTL défini), vous voulez conserver les données qui sont les plus consultées, même si ces données sont restées inchangées pendant quelques heures. allkeys-lru ou allkeys-lfu sont idéaux.

# Utiliser LFU pour conserver les objets véritablement 'chauds', quelle que soit leur date de création
CONFIG SET maxmemory-policy allkeys-lfu

Surveillance et Optimisation

Après avoir sélectionné une politique, une surveillance continue est essentielle. Vous devez suivre les métriques suivantes via la commande INFO :

• used_memory : À quel point vous êtes proche de la limite maxmemory.
• evicted_keys : Le taux auquel Redis supprime les données. Un taux d'éviction constamment élevé indique que votre paramètre maxmemory est trop bas pour votre charge de travail, ou que votre politique d'éviction est trop agressive.
• Taux de succès du cache de l'application : La mesure ultime du succès. Si votre taux de succès diminue lorsque la pression mémoire augmente, votre sélection de politique ou votre limite maxmemory doit être ajustée.

Meilleure Pratique : Lors de l'ajustement de maxmemory, laissez toujours une marge de sécurité (par exemple, 10 à 20 % de mémoire libre) pour tenir compte du tampon de réplication, du tampon de commande et des surcoûts potentiels des structures de données internes de Redis.

Conclusion

Les politiques d'éviction de Redis offrent un contrôle granulaire sur le comportement de votre cache sous pression mémoire. Il n'existe pas de politique unique « meilleure » ; le choix entre l'éviction basée sur LRU, LFU ou TTL doit correspondre précisément à vos modèles d'accès aux données et à vos exigences métier. En sélectionnant soigneusement la politique appropriée — telle que allkeys-lru pour le cache général ou volatile-ttl pour les magasins de sessions — vous pouvez maximiser l'efficacité du cache et garantir des performances robustes pour vos opérations de données à haute vitesse.