Stratégies de mise en cache : mise en cache Redis, CDN et HTTP pour les applications Web

La mise en cache est la technique la plus efficace pour améliorer les performances des applications. Un cache bien conçu peut réduire la charge de la base de données de 90 %, réduire les temps de réponse de 200 ms à 2 ms et économiser des milliers de dollars en coûts d'infrastructure chaque mois. Pourtant, la mise en cache est également l'un des domaines les plus mal compris du génie logiciel : les bogues d'invalidation créent des données obsolètes, les bousculades de cache font tomber les serveurs et les TTL mal choisis gaspillent de la mémoire ou servent du contenu obsolète.

Points clés à retenir

• Concevoir la mise en cache en couches : du navigateur au CDN en passant par l'application (Redis) et le cache de requêtes de base de données - chaque couche gère différentes caractéristiques de données.
• Le modèle de mise en cache Redis est le modèle par défaut le plus sûr : lire à partir du cache, revenir à la base de données, remplir le cache en cas d'échec
• Les en-têtes de cache HTTP (Cache-Control, ETag, Vary) éliminent entièrement les requêtes inutiles : la requête la plus rapide est celle qui n'atteint jamais votre serveur.
• L'invalidation du cache est plus difficile que la mise en cache : utilisez l'expiration basée sur la durée de vie comme stratégie principale et l'invalidation basée sur les événements pour la fraîcheur des données critiques.

---

La hiérarchie du cache

Une mise en cache efficace fonctionne par couches, chaque couche étant optimisée pour différentes exigences de latence, de capacité et de fraîcheur.

Couche 1 : Cache du navigateur

Le cache du navigateur est le cache le plus rapide et le moins cher car il élimine entièrement la requête réseau. Les en-têtes HTTP Cache-Control contrôlent le comportement de mise en cache du navigateur.

Pour les ressources statiques avec des noms de fichiers hachés (comme la sortie de build Next.js), définissez Cache-Control: public, max-age=31536000, immutable. Le hachage du contenu dans le nom de fichier garantit que le contenu modifié obtient une nouvelle URL, afin que vous puissiez mettre en cache de manière agressive sans vous soucier du contenu obsolète.

Pour les pages HTML et les réponses API, utilisez des durées de vie plus courtes avec revalidation : Cache-Control: public, max-age=60, stale-while-revalidate=300. Cela sert le contenu mis en cache pendant 60 secondes, puis est revalidé en arrière-plan tout en continuant à diffuser le contenu obsolète pendant 5 minutes maximum.

Couche 2 : Cache périphérique CDN

Un CDN met en cache le contenu sur des serveurs périphériques distribués dans le monde entier, réduisant ainsi la latence en diffusant le contenu depuis l'emplacement le plus proche de chaque utilisateur. Pour une base d'utilisateurs mondiale, la mise en cache CDN réduit la latence moyenne de 200 à 500 ms (aller-retour du serveur d'origine) à 10 à 50 ms (bord le plus proche).

Que mettre en cache sur CDN :

• Tous les actifs statiques (JavaScript, CSS, images, polices)
• Pages de marketing public (avec un TTL court pour la fraîcheur du contenu)
• Pages du catalogue de produits (TTL de 5 à 15 minutes pour le commerce électronique)
• Réponses API pour les données publiques (listes de produits, contenu du blog)

Ce qu'il ne faut PAS mettre en cache sur CDN :

• Réponses API authentifiées (données spécifiques à l'utilisateur)
• Pages de panier et de paiement
• Pages du panneau d'administration
• Points de terminaison du webhook
• Toute réponse avec les en-têtes Set-Cookie

Couche 3 : Cache d'application (Redis)

Redis fournit un accès avec une latence de l'ordre de la microseconde aux données mises en cache, ce qui le rend idéal pour les données coûteuses à calculer ou fréquemment consultées. Contrairement à la mise en cache CDN, Redis peut mettre en cache des données authentifiées et spécifiques à l'utilisateur, car votre application contrôle l'accès.

Couche 4 : Cache de requêtes de base de données

PostgreSQL maintient un cache tampon (shared_buffers) qui met en cache les pages de table et d'index fréquemment consultées en mémoire. Bien qu'elle ne soit pas directement contrôlable par requête, une configuration appropriée garantit que les données chaudes restent en mémoire. Pour les requêtes de reporting, envisagez des vues matérialisées qui précalculent des agrégations coûteuses.

---

Modèles de mise en cache Redis

Redis est le cache au niveau de l'application le plus populaire pour les applications Web, prenant en charge les chaînes, les hachages, les listes, les ensembles, les ensembles triés et les flux. Le modèle que vous choisissez détermine le comportement de votre cache dans les cas extrêmes.

Cache-Aside (chargement paresseux)

Le cache-aside est le modèle par défaut le plus sûr. L'application vérifie d'abord Redis. En cas d'accès au cache, il renvoie les données mises en cache. En cas d'échec du cache, il interroge la base de données, stocke le résultat dans Redis avec un TTL et renvoie les données.

Avantages :

• Seules les données demandées sont mises en cache (pas de perte de mémoire sur les données inutilisées)
• L'échec de la base de données n'affecte que les échecs de cache, pas les accès au cache
• Simple à mettre en œuvre et à raisonner

Inconvénients :

• La première requête pour chaque clé atteint toujours la base de données (démarrage à froid)
• Données périmées possibles entre la mise à jour de la base de données et l'expiration du cache

Écriture directe

Dans la mise en cache en écriture directe, chaque écriture dans la base de données met également à jour le cache immédiatement. L'application écrit à la fois dans la base de données et dans Redis au cours de la même opération.

Avantages :

• Le cache est toujours frais - pas de fenêtre de données obsolètes
• Les performances de lecture sont toujours rapides (aucun cache ne manque après l'écriture initiale)

Inconvénients :

• La latence d'écriture augmente (deux écritures par opération)
• Le cache peut contenir des données qui ne sont jamais lues (mémoire gaspillée)
• Nécessite une gestion minutieuse des erreurs lorsqu'une écriture réussit et que l'autre échoue

Write-Behind (Réécriture)

La mise en cache en écriture différée écrit immédiatement sur Redis mais reporte l'écriture de la base de données à un processus en arrière-plan. Cela réduit la latence d'écriture mais introduit un risque de perte de données si Redis échoue avant la fin de l'écriture de la base de données.

À utiliser avec parcimonie : ce modèle est approprié pour les compteurs d'analyse, la limitation de débit et les données de session où une perte de données occasionnelle est acceptable, et non pour les transactions financières ou les inventaires.

Prévention de la bousculade du cache

Une ruée vers le cache se produit lorsqu'une clé de cache populaire expire et que des centaines de requêtes simultanées interrogent toutes simultanément la base de données pour la reconstruire. Cela peut surcharger la base de données.

Stratégies de prévention :

1. Stale-while-revalidate -- sert des données légèrement obsolètes pendant qu'une requête reconstruit le cache en arrière-plan
2. Verrouillage Mutex - utilisez Redis SETNX pour vous assurer qu'une seule requête reconstruit le cache pendant que d'autres attendent ou servent des données obsolètes
3. Expiration anticipée probabiliste - recalcule de manière aléatoire avant l'expiration du TTL, répartissant les reconstructions dans le temps au lieu de les concentrer à l'expiration.

---

Conception de la stratégie TTL

Les valeurs de durée de vie (TTL) déterminent la durée pendant laquelle les données restent dans le cache. Trop court et vous obtenez des échecs de cache excessifs. Trop longtemps et vous diffusez des données obsolètes.

TTL coulissant vs TTL fixe

Le TTL fixe fait expirer la clé à un moment défini après la création. Le TTL coulissant réinitialise l’expiration à chaque accès à la clé. Utilisez un TTL glissant pour les données de session (maintenez les sessions actives actives) et un TTL fixe pour les caches de contenu (assurez une actualisation régulière à partir de la source).

---

Analyse approfondie des en-têtes de cache HTTP

La mise en cache HTTP est puissante car elle fonctionne à chaque couche : le navigateur, le CDN, les proxys et les équilibreurs de charge comprennent tous les mêmes en-têtes.

Directives de contrôle du cache

• public -- n'importe quel cache (navigateur, CDN, proxy) peut stocker la réponse
• privé -- seul le navigateur peut mettre en cache (pas le CDN ou les proxys) -- à utiliser pour les réponses authentifiées
• no-cache -- met en cache la réponse mais revalide avec le serveur avant de l'utiliser (nom trompeur -- il met en cache)
• no-store -- ne pas mettre en cache du tout (données sensibles comme les pages bancaires)
• max-age=N -- le cache est valide pendant N secondes
• s-maxage=N -- Durée du cache CDN/proxy (remplace l'âge maximum pour les caches partagés)
• stale-while-revalidate=N -- diffuse du contenu obsolète pendant N secondes tout en revalidant en arrière-plan
• immuable -- le contenu ne changera jamais (à utiliser avec des URL hachées de contenu)

ETag et requêtes conditionnelles

Les ETags fournissent une validation du cache basée sur le contenu. Le serveur génère un hachage du contenu de la réponse et l'envoie comme en-tête ETag. Lors des requêtes suivantes, le navigateur envoie l'ETag dans un en-tête If-None-Match. Si le contenu n'a pas changé, le serveur répond par 304 Not Modified (no body), économisant ainsi la bande passante.

Utilisez des ETags pour les réponses API lorsque le contenu change de manière imprévisible et que la mise en cache basée sur la durée de vie serait trop agressive ou trop conservatrice.

Varier l'en-tête

L'en-tête Vary indique aux caches que la réponse dépend d'en-têtes de requête spécifiques. Par exemple, Vary: Accept-Encoding signifie que les versions gzip et Brotli sont mises en cache séparément. Vary: Accept-Language met en cache différentes versions linguistiques séparément.

Soyez prudent avec Vary : chaque combinaison unique d'en-têtes variés crée une entrée de cache distincte. Vary: Cookie désactive efficacement la mise en cache car chaque utilisateur dispose de cookies différents.

---

## Stratégies d'invalidation du cache

L’invalidation du cache est notoirement l’un des deux problèmes difficiles en informatique. L'objectif est de supprimer ou de mettre à jour les données mises en cache lorsque les données sources changent, sans introduire de lectures obsolètes ni d'absences de cache inutiles.

Expiration basée sur le TTL

La stratégie d'invalidation la plus simple et la plus fiable. Définissez un TTL sur chaque clé mise en cache et acceptez que les données puissent être légèrement obsolètes dans la fenêtre TTL. Pour la plupart des cas d'utilisation, un TTL de 5 minutes offre un excellent équilibre entre fraîcheur et performances.

Invalidation basée sur les événements

Lorsqu'un enregistrement de base de données change, publiez un événement qui déclenche la suppression du cache. Cela fournit une fraîcheur quasi instantanée mais ajoute de la complexité et des modes de défaillance. Si l'événement est perdu (problème de réseau, échec de file d'attente), le cache sert des données obsolètes jusqu'à l'expiration de la durée de vie.

Utilisez l'invalidation basée sur les événements pour les données critiques telles que les inventaires et les prix, et comptez sur le TTL pour tout le reste.

Invalidation basée sur les balises

Certains systèmes de mise en cache prennent en charge le marquage des entrées de cache avec des étiquettes. Lorsque vous invalidez une balise, toutes les entrées avec cette balise sont purgées. Ceci est utile pour invalider toutes les données mises en cache liées à une entité spécifique (par exemple, tous les caches liés aux produits lorsqu'un catalogue de produits est mis à jour).

---

Questions fréquemment posées

Comment puis-je décider quoi mettre en cache ?

Mettez en cache des données lues fréquemment, coûteuses à calculer et tolérantes à une brève obsolescence. Les pages du catalogue de produits, les autorisations des utilisateurs, les métriques calculées du tableau de bord et les données de configuration sont d'excellents candidats. Les paniers d'achat, les inventaires en temps réel et les transactions financières ne doivent généralement pas être mis en cache ou doivent utiliser des durées de vie très courtes avec une invalidation déclenchée par des événements.

Que se passe-t-il lorsque Redis tombe en panne ?

Avec le modèle de mise en cache, votre application revient à interroger directement la base de données. Les temps de réponse augmentent mais l'application reste fonctionnelle. Concevez votre application pour gérer les échecs de cache avec élégance : Redis doit être une optimisation des performances, et non un point de défaillance unique.

Quelle quantité de mémoire dois-je allouer à Redis ?

Surveillez votre taux de réussite du cache et l'utilisation de la mémoire. Un taux de réussite supérieur à 95 % avec une utilisation de la mémoire inférieure à 80 % indique un bon dimensionnement. Si le taux de réussite tombe en dessous de 90 %, soit vous avez besoin de plus de mémoire, soit vos durées de vie sont trop courtes. Commencez avec 1 à 2 Go pour la plupart des applications et évoluez en fonction des données de surveillance.

Dois-je utiliser Redis ou Memcached ?

Redis est le meilleur choix par défaut pour la plupart des applications. Il prend en charge davantage de types de données, d'options de persistance, de pub/sub pour l'invalidation basée sur des événements et de scripts Lua pour les opérations atomiques. Memcached est plus simple et légèrement plus rapide pour la mise en cache pure de valeurs-clés à une échelle extrême, mais Redis couvre davantage de cas d'utilisation.

Comment puis-je empêcher la diffusion de données obsolètes après un déploiement ?

Incluez un identifiant de version dans vos clés de cache (par exemple, des clés de préfixe avec la version de déploiement ou une version de schéma). Lors du déploiement, la nouvelle version utilise de nouvelles clés de cache et les anciennes clés expirent naturellement via TTL. Vous pouvez également vider l’intégralité du cache lors du déploiement si votre application gère correctement les caches froids.

---

Quelle est la prochaine étape

Commencez par implémenter des en-têtes de cache HTTP pour vos ressources statiques et vos pages publiques : cela permet une amélioration immédiate des performances sans aucune modification d'application. Ajoutez ensuite la mise en cache Redis pour vos requêtes de base de données et vos points de terminaison d'API les plus coûteux.

Pour obtenir une image complète de l'optimisation des performances, consultez notre guide des piliers sur la mise à l'échelle de votre plateforme commerciale. Pour optimiser la source de données qui alimente votre cache, lisez notre guide sur l'optimisation des requêtes de base de données.

ECOSIRE implémente des architectures de mise en cache pour les plateformes fonctionnant sur Odoo ERP et Shopify. Contactez notre équipe pour un examen de la stratégie de mise en cache.

---

Publié par ECOSIRE — aider les entreprises à évoluer grâce à des solutions basées sur l'IA dans Odoo ERP, Shopify eCommerce et OpenClaw AI.