Le cache Redis pour applications web : quand vous en avez besoin, et comment l'utiliser sans regrets

« Devrions-nous ajouter Redis ? » est la question que j'entends dans presque toutes les conversations de performance, généralement juste après que quelqu'un a suggéré un plus gros serveur. Le cache est réellement l'un des outils les plus puissants dont nous disposons — mon propre travail d'optimisation de bases de données utilise Redis en permanence. Mais un cache est aussi le moyen le plus facile de rendre une application rapide et fausse, et le deuxième moyen le plus facile de passer des semaines à régler quelque chose qu'un seul index aurait corrigé en un après-midi. Voyons quand Redis est la réponse, et comment l'utiliser comme tel.

D'abord, la question inconfortable : le cache masque-t-il une requête corrigeable ?

Un cache stocke le résultat d'un travail pour ne pas le répéter. Cela le rend parfait pour un travail coûteux et légitimement répété — et inutile pour un travail qui n'est coûteux que parce qu'il est cassé. Si une requête prend 2 secondes faute d'index, la mettre en cache vous donne une requête de 2 secondes parfois et une réponse périmée le reste du temps ; corriger l'index vous donne une requête de 10 millisecondes toujours. Mon ordre des opérations ne change jamais : trouver et corriger les requêtes lentes d'abord, tuer les motifs N+1 ensuite, et alors mettre en cache ce qui reste réellement lourd. Redis est l'amplificateur, pas l'atelier de réparation.

Ce qui mérite une place dans le cache

Le profil que je recherche : lu souvent, modifié rarement, coûteux à calculer. Concrètement, dans les applications sur lesquelles je travaille :

• Les données de référence et de catalogue — catégories de produits, listes de pays/villes, grilles tarifaires, configuration. Lus à chaque page, modifiés par un administrateur deux fois par mois. Candidats parfaits.

• Les agrégations coûteuses — statistiques de tableau de bord, totaux de rapports, « meilleurs produits de la semaine ». Les recalculer à chaque requête est un gaspillage ; les calculer à chaque expiration du cache est largement assez frais pour presque tous les besoins métier.

• Les fragments rendus et réponses d'API — le bloc des produits populaires d'une page d'accueil, les points d'accès chauds d'une API publique. Mettez en cache la sortie, pas les rouages internes.

• Sessions, limites de débit, files d'attente, classements — le terrain de jeu naturel de Redis au-delà du cache proprement dit ; s'il est déjà dans votre pile pour cela, le coût marginal d'y ajouter le cache est faible.

Le profil inverse — change constamment, doit toujours être exact (stock en direct pour le dernier exemplaire, soldes de compte en plein paiement) — est là où les caches vont causer des incidents. Certains de ces cas peuvent tout de même utiliser Redis comme source de vérité avec des opérations atomiques, mais c'est une décision d'architecture, pas un « ajout de cache ».

L'invalidation : la partie difficile dont tout le monde vous prévient (à raison)

La vieille blague dit que l'informatique a deux problèmes difficiles : l'invalidation du cache et le nommage des choses. Le manuel pratique :

Le TTL d'abord (expiration par le temps). La stratégie la plus simple et le bon défaut pour la plupart des données : mettre en cache 5 minutes, une heure, un jour — selon la fraîcheur que le métier peut tolérer. Des données de catalogue à 15 minutes sont à l'épreuve du temps pour tout usage sain. Commencez là ; la complexité plus tard.

L'invalidation par événement pour les données que les utilisateurs voient changer. Quand un administrateur modifie un produit, supprimez (ou rafraîchissez) les clés de cache de ce produit. Cela exige de la discipline dans la conception des clés — étiquetez-les par entité (product:42, category:7:products) pour purger précisément plutôt que de tout vider.

Ne laissez jamais le cache être la seule copie. Redis est de la mémoire : il peut être évincé, redémarré, perdu. Tout ce qui doit survivre vit dans la base de données ; le cache est un accélérateur jetable. Si perdre tout votre cache à 3 heures du matin serait une panne plutôt qu'un matin lent, la conception est fausse.

La protection contre les stampedes sur les clés chaudes. Quand une clé très populaire expire, une centaine de requêtes simultanées peuvent toutes la recalculer en même temps et s'abattre sur la base — le « troupeau tonnant ». Verrouillage, rafraîchissement anticipé ou service légèrement périmé pendant qu'un seul travailleur rafraîchit sont les réponses standard ; sur les points d'accès vraiment chauds, cela compte plus que le cache lui-même.

Règles de dimensionnement et de bon sens

• Surveillez le taux de réussite (hit ratio). Un cache à 40 % de réussite est surtout décoratif ; 90 % et plus font un vrai travail. Mesurez les temps de réponse avant/après comme vous mesurez les corrections de requêtes — des chiffres, pas des impressions.

• Mettez en cache à la bonne couche. Le cache de page/réponse complète (ou un CDN) pour le contenu public bat l'ingéniosité applicative ; le cache d'objets pour les données personnalisées ou composées. Ne reconstruisez pas au niveau application ce que le bord du réseau vous donne gratuitement.

• La mémoire est le budget. Redis vit en RAM ; décidez d'une politique d'éviction (allkeys-lru est le défaut sain habituel) et surveillez l'empreinte à mesure que les données grandissent. Un cache sans borne est une panne différée.

Alors — avez-vous besoin de Redis ?

Si vos pages recalculent les mêmes résultats coûteux pour chaque visiteur, oui, presque certainement, et ce sera comme de la magie. Si votre base est lente parce que ses requêtes sont non indexées et bavardes, Redis masquera poliment le problème jusqu'à ce que le cache expire à votre moment de plus fort trafic. Réparez les fondations, puis mettez en cache les pics : cette combinaison — une base réglée plus un cache délibéré — est ce qui rend les applications instantanées à l'échelle. C'est exactement le duo que je construis dans mon service d'architecture et d'optimisation de bases de données. Si vous ne savez pas de quel côté de cette ligne se situe votre application, décrivez les symptômes et je vous dirai honnêtement lequel il vous faut en premier.