La mise en cache dans les applications : délais d'expiration, invalidation et protection contre la ruée

Ce que c'est

Dans le modèle « cache-aside », l'application interroge d'abord le cache ; en cas d'échec, elle lit la source, dépose le résultat avec un délai d'expiration et le renvoie. Redis documente les briques de base : EXPIRE fixe un délai après lequel la clé est automatiquement supprimée, et SET avec l'option NX n'écrit que si la clé n'existe pas encore - la base d'un verrou simple. Au niveau HTTP, la RFC 9111 règle avec max-age le même principe de fraîcheur limitée ; les caches applicatifs ne suivent aucune norme, leurs règles se fixent soi-même.

Pourquoi c'est important

Un cache réduit la charge et la latence, mais une entrée périmée après une écriture est une erreur de justesse difficile à reproduire : elle ne survient que dans la fenêtre entre l'écriture et l'expiration, et disparaît lors d'une reproduction. La stratégie d'invalidation fait donc partie de la conception, pas d'une correction ultérieure.

Comment l'appliquer

• Fixer, par catégorie de données, l'âge maximal acceptable d'une valeur, et régler le délai d'expiration en conséquence ; un délai court limite les dégâts de toute invalidation oubliée.
• À l'écriture, supprimer les clés concernées plutôt que de les écraser : la suppression est idempotente et ne peut laisser subsister une ancienne valeur si deux écrivains se dépassent l'un l'autre. Un lecteur dépassé par une écriture entre la lecture en base de données et l'écriture dans le cache peut malgré tout déposer une valeur périmée ; cette fenêtre n'est limitée que par le délai d'expiration.
• Inclure un identifiant de version ou de schéma dans la clé (kunde:v3:123), afin qu'un déploiement avec une nouvelle structure de valeur ne lise pas d'anciennes entrées ; les anciennes expirent d'elles-mêmes.
• Penser aux clés dérivées : quand un objet change, des listes, des compteurs et des résultats de recherche qui le contiennent sont eux aussi concernés. Soit supprimer leurs clés également, soit leur donner un délai plus court.
• Éviter la ruée (« stampede ») : quand une clé très sollicitée expire, une seule requête devrait interroger la source. Avec SET sperre:<schlüssel> 1 NX EX 5, un processus obtient le droit de recharger ; les autres attendent brièvement ou servent l'ancienne valeur encore présente. La documentation de Redis appelle SET … NX EX un verrou simple et renvoie à Redlock pour des verrous tolérants aux pannes ; pour la protection contre la ruée, où un échec ne signifie qu'un second rechargeur, la forme simple suffit.
• Mettre en cache les résultats négatifs (« introuvable ») avec un délai court quand de nombreuses requêtes visent des clés manquantes.
• Mesurer le taux de succès et la charge de la source ; un cache sans succès ne coûte, à chaque échec, qu'une latence supplémentaire.

Pièges

Des données propres à un utilisateur sous une clé commune. Traiter le cache comme un stockage durable, alors qu'un redémarrage le vide. Des délais d'expiration fixés et vérifiés sur des hôtes différents dont l'horloge diverge. Un verrou sans délai d'expiration, qui n'est plus jamais libéré après un plantage du processus de rechargement.