Configuration de Redis comme cache multicouche efficace

Redis est rapide car il conserve les données de travail en mémoire, mais un cache non géré peut toujours remplir l'hôte et provoquer des échecs d'écriture. Lorsque vous utilisez Redis comme cache multicouche entre votre application et une base de données plus lente, les décisions clés sont les limites de mémoire, la politique d'éviction, la discipline des TTL et la question de savoir si les données du cache doivent être persistées.

Ce guide se concentre sur la configuration de Redis pour les charges de travail de cache, et non pour le stockage de données principal.

Comprendre les couches de cache Redis

Dans de nombreuses conceptions d'applications, Redis est le cache partagé derrière un cache plus petit dans le processus. Votre application peut conserver localement quelques valeurs chaudes pendant des millisecondes, tandis que Redis stocke un ensemble plus large d'objets réutilisables pendant des secondes ou des minutes. Cela fait de Redis la couche qui protège votre base de données en cas de pic de trafic.

Une configuration efficace repose sur deux domaines principaux :

1. Gestion de la mémoire : Définir une limite stricte sur la quantité de mémoire que Redis peut consommer.
2. Politiques d'éviction : Déterminer comment Redis décide quelles clés supprimer lorsque la limite de mémoire est atteinte.

1. Définir les limites de mémoire pour la stabilité

Empêcher Redis de consommer toute la mémoire système disponible est primordial pour la stabilité de l'hôte. La directive maxmemory fixe un plafond absolu pour la mémoire allouée à l'ensemble de données (hors frais généraux). Si cette limite est atteinte, Redis commencera à évincer les clés en fonction de la politique configurée.

Directive de configuration : maxmemory

Ce paramètre est crucial pour les environnements de production. Une bonne pratique courante consiste à laisser une marge pour les tâches du système d'exploitation et les frais généraux de Redis (par exemple, structures de données internes, tampons de réplication).

Exemple de configuration (redis.conf) :

# Définir l'utilisation maximale de la mémoire à 4 Go
maxmemory 4gb

Astuce : Utilisez toujours des suffixes lisibles par l'homme (par exemple, 100mb, 2gb) pour une gestion plus facile de la configuration.

Application de la politique de mémoire

Si maxmemory est défini et que maxmemory-policy reste noeviction, les commandes nécessitant plus de mémoire peuvent échouer une fois la limite atteinte. Pour un cache, choisissez une politique d'éviction qui permet à Redis de supprimer les anciennes entrées du cache au lieu de rejeter les écritures normales du cache.

2. Choisir la bonne politique d'éviction (maxmemory-policy)

Cette directive définit l'algorithme que Redis utilise pour sélectionner les clés à supprimer lorsque la limite de mémoire est dépassée. Le choix de la politique correcte dépend fortement des modèles d'accès de vos données d'application.

Politiques volatiles vs non volatiles

Les politiques sont généralement classées en fonction de la prise en compte ou non de l'expiration du Time-To-Live (TTL) définie sur les clés :

• Volatile : Ne prend en compte que les clés qui ont un temps d'expiration défini (EXPIRE ou SETEX).
• Toutes les clés : Prend en compte toutes les clés, quel que soit le TTL.

Pour une couche de cache pure où la plupart des éléments ont une expiration explicite, les politiques volatiles sont excellentes. Si vous vous fiez à la logique d'application externe pour gérer l'obsolescence, vous pouvez préférer les politiques non volatiles.

Explication des algorithmes d'éviction clés

A. Moins récemment utilisé (LRU)

C'est la politique la plus courante et souvent par défaut pour la mise en cache générale. Elle supprime la clé qui n'a pas été consultée depuis le plus longtemps. Elle fonctionne mieux lorsque les modèles d'accès suivent le principe de localité temporelle (les données récemment consultées sont susceptibles d'être consultées à nouveau bientôt).

Configuration :

maxmemory-policy allkeys-lru

B. Moins fréquemment utilisé (LFU)

LFU suit la fréquence à laquelle une clé a été consultée. Elle évince les clés avec une fréquence d'accès estimée plus faible. Cela fonctionne bien lorsque votre charge de travail a un ensemble stable de clés populaires qui devraient survivre à des analyses occasionnelles ou à des lectures uniques.

Configuration :

maxmemory-policy allkeys-lfu

C. Éviction basée sur le TTL

L'éviction basée sur le TTL est utile lorsque les clés ont des temps d'expiration significatifs et que les clés les plus proches de l'expiration sont les plus sûres à supprimer.

Configuration :

maxmemory-policy volatile-ttl

Cette politique ne prend en compte que les clés avec une expiration définie. Si de nombreuses clés n'ont pas de TTL, Redis peut encore manquer de clés évincables et rejeter les écritures.

D. Éviction aléatoire

L'éviction aléatoire est simple et parfois acceptable pour les données de cache jetables, mais elle est rarement le premier choix lorsque votre cache a des modèles d'accès clairs.

maxmemory-policy allkeys-random

3. Définir les TTL de manière cohérente

Les politiques d'éviction sont une soupape de pression, pas votre seule stratégie d'invalidation de cache. La plupart des clés de cache doivent avoir une expiration qui correspond à la valeur commerciale des données.

Par exemple, une page de détail de produit peut mettre en cache un fragment rendu pendant cinq minutes :

redis-cli SET product:123:html "$HTML" EX 300

Une recherche de permissions utilisateur peut nécessiter un TTL beaucoup plus court car les données obsolètes sont plus risquées :

redis-cli SET user:42:permissions "$JSON" EX 30

Évitez de mélanger des clés permanentes dans la même base de données Redis que des clés de cache jetables, sauf si vous utilisez une politique allkeys-* et que vous êtes à l'aise avec l'éviction de n'importe quelle clé. Si certaines données ne doivent jamais être évincées, conservez-les dans une instance Redis distincte ou une base de données avec une politique différente.

4. Décidez si la persistance du cache est utile

Pour un cache pur, la persistance Redis est facultative. La désactivation de RDB et AOF réduit les E/S disque et la complexité du redémarrage, mais chaque clé de cache est perdue lors du redémarrage de Redis.

save ""
appendonly no

C'est acceptable lorsque votre application peut reconstruire le cache à partir de la base de données. Si le préchauffage du cache est coûteux ou qu'un cache froid surchargerait la base de données, gardez les instantanés RDB ou AOF activés et testez le comportement de redémarrage sous charge.

5. Surveiller la santé du cache

Utilisez les métriques Redis pour confirmer que le cache est utile :

redis-cli INFO memory
redis-cli INFO stats
redis-cli INFO keyspace

Surveillez ces champs en particulier :

Métrique	Ce qu'elle vous indique
used_memory_human	Mémoire actuelle consommée par Redis.
maxmemory_human	Plafond de mémoire configuré.
evicted_keys	Si Redis évince sous pression.
keyspace_hits et keyspace_misses	Si le cache sert des lectures utiles.
expired_keys	Si le nettoyage TTL est actif.

Si evicted_keys augmente rapidement et que le taux de succès chute, augmentez la mémoire, raccourcissez les TTL pour les clés de faible valeur, ou divisez les charges de travail bruyantes dans un cache séparé.

Exemple de configuration de cache

Voici un point de départ raisonnable pour une instance Redis dédiée aux entrées de cache jetables :

maxmemory 4gb
maxmemory-policy allkeys-lfu
save ""
appendonly no

Pour un cache où chaque clé a un TTL soigneusement choisi :

maxmemory 4gb
maxmemory-policy volatile-ttl

Utilisez CONFIG GET maxmemory maxmemory-policy pour vérifier les paramètres actifs :

redis-cli CONFIG GET maxmemory maxmemory-policy

À retenir

Traitez la configuration du cache Redis comme un problème de contrôle de capacité. Définissez maxmemory, choisissez une politique d'éviction qui correspond à votre modèle d'accès, donnez aux clés du cache des TTL explicites, et décidez si la persistance vaut les E/S disque. Ensuite, surveillez le taux de succès, les évasions et la croissance de la mémoire pour que le cache protège votre base de données au lieu de devenir le prochain goulot d'étranglement.