Guide pour choisir des politiques d'éviction Redis efficaces

Redis est rapide car il conserve les données en mémoire, mais la mémoire est limitée. Lorsque votre instance Redis atteint maxmemory, la politique d'éviction décide si Redis supprime des clés, rejette les écritures, ou évince uniquement les clés avec un temps d'expiration.

Choisir une politique d'éviction Redis efficace est crucial lorsque Redis agit comme cache, magasin de sessions ou base de données à usage mixte. Une mauvaise politique peut évincer des clés importantes ou faire échouer les écritures lors d'un pic de trafic.

---

Comprendre l'éviction Redis et maxmemory

Les politiques d'éviction n'entrent en jeu que lorsque l'utilisation 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 n'applique pas de limite mémoire pour les écritures normales. Sur un hôte dédié, cela peut éventuellement entraîner une pression sur la mémoire du système d'exploitation, donc les déploiements de cache en production définissent généralement une limite explicite.

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 Redis intégrées

Redis propose plusieurs politiques distinctes. Elles 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 Least Recently Used (LRU) ou Least Frequently Used (LFU), et celles ciblant les clés avec un Time To Live (TTL) défini.

1. Politiques sans exigence de TTL

Ces politiques opèrent sur toutes les clés de la base de données, qu'elles aient ou non un temps d'expiration défini.

noeviction

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

allkeys-lru

Évince 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 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 mis en cache.

allkeys-lfu

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

allkeys-random

Évince les clés choisies aléatoirement jusqu'à ce que la limite mémoire soit satisfaite. Cela est rarement recommandé pour les caches de production, sauf si le modèle d'accès aux données est complètement uniforme et imprévisible.

2. Politiques nécessitant un TTL (clés volatiles)

Ces politiques ne considèrent que les clés qui ont un temps d'expiration explicite (EXPIRE ou SETEX) défini. Elles ignorent les clés non expirantes lors de l'éviction.

volatile-lru

Évince les clés les moins récemment utilisées parmi celles qui ont une expiration définie.

volatile-lfu

Évince les clés les moins fréquemment utilisées parmi celles qui ont une expiration définie.

volatile-random

Évince une clé aléatoire parmi celles qui ont une expiration définie.

volatile-ttl

Évince la clé avec le temps restant le plus court (TTL) en premier. Cela est idéal pour les données sensibles au temps, comme les jetons de session ou l'état temporaire de l'application, garantissant que les données plus anciennes et sur le point d'expirer sont nettoyées en premier.

---

Sélectionner la politique adaptée à votre charge de travail

La politique d'éviction optimale dépend entièrement de ce que vous mettez en cache et de comment 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, indépendamment du TTL. Simple et très efficace.
Données sensibles au temps (ex. jetons, sessions de courte durée)	volatile-ttl	Évince préférentiellement les clés avec le TTL restant le plus court.
Cache de données chaudes (forte asymétrie d'accès)	allkeys-lfu ou volatile-lfu	Protège les éléments fréquemment accédés contre l'éviction due à une inactivité récente.
Rétention obligatoire des données (aucune perte autorisée)	noeviction	Empêche la perte de données en générant des erreurs sur les é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, volatile-lfu, ou volatile-ttl	Si vos clés non expirantes sont essentielles, utilisez une politique volatile pour les protéger en n'évincant que les clés explicitement expirantes.

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

Si Redis est principalement utilisé pour stocker les sessions utilisateur, définissez un TTL explicite sur chaque clé de session, par exemple 30 minutes. volatile-ttl peut fonctionner lorsque la durée de vie restante est le signal le plus important. Si votre application rafraîchit les TTL des sessions lors de l'activité, les sessions actives conservent naturellement un TTL restant plus long. Si elle ne rafraîchit pas les TTL, envisagez plutôt volatile-lru ou volatile-lfu.

# 1. Définir maxmemory (ex. 10 Go)
CONFIG SET maxmemory 10gb

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

Exemple pratique : Implémentation d'un cache HTTP

Pour la mise en cache de réponses HTTP complètes (qui n'ont pas toujours un TTL défini), vous souhaitez conserver les données les plus souvent accédées, même si ces données sont restées inutilisées pendant quelques heures. allkeys-lru ou allkeys-lfu sont idéaux.

# Utiliser LFU pour conserver les objets vraiment 'chauds', indépendamment de leur date de création
CONFIG SET maxmemory-policy allkeys-lfu

Surveillance et réglage

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 des 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 choix de politique ou votre limite maxmemory nécessite un ajustement.

Meilleure pratique : Lors du réglage de maxmemory, laissez toujours une marge de sécurité (par exemple, 10-20 % de mémoire libre) pour tenir compte de la mise en mémoire tampon de réplication, de la mise en mémoire tampon des commandes et des frais généraux potentiels des structures de données internes de Redis.

Conclusion finale

Commencez par allkeys-lru pour un cache général, allkeys-lfu lorsqu'un petit ensemble de clés chaudes domine le trafic, et une politique volatile-* uniquement lorsque les clés non expirantes doivent être protégées. Ensuite, surveillez evicted_keys, le taux de succès de l'application et les erreurs d'écriture sous charge avant de finaliser la politique.