Si vous êtes un développeur backend, la mise en cache est une solution incontournable chaque fois que vous avez besoin d'accélérer votre application Web. Cependant, il y a beaucoup de choses qui manquent à propos de la mise en cache lors du choix de la bonne stratégie de mise en cache pour votre application Web. Par conséquent, dans cet article, nous discuterons des différentes stratégies de mise en cache disponibles et de la manière de choisir celle qui convient à votre cas d'utilisation. Qu'est-ce que la mise en cache ? En termes plus simples, la mise en cache est une technique de mise en mémoire tampon dans laquelle nous stockons les données fréquemment consultées dans une mémoire ou un espace temporaire pour les rendre facilement disponibles et réduire la charge de travail de notre application, serveur ou base de données. Il peut être implémenté à différents niveaux dans une application Web en fonction du cas d'utilisation. Mise en cache à différents niveaux dans une application Web La mise en cache se produit à différents niveaux dans une application Web, comme suit : Mise en cache périphérique ou CDN (réseau de diffusion de contenu) Un CDN est utilisé pour mettre en cache des actifs statiques (tels que des images, des vidéos ou des pages Web) dans des serveurs répartis géographiquement afin qu'il puisse envoyer le contenu plus rapidement à l'utilisateur final à l'aide du cache. Considérez un CDN comme une chaîne d'épiceries : au lieu de parcourir des centaines de kilomètres jusqu'aux champs où la nourriture est cultivée, les acheteurs se rendent à leur épicerie locale, qui a encore besoin de se déplacer mais qui est considérablement plus proche. Faire l'épicerie prend quelques minutes plutôt que des jours puisque les épiceries stockent des aliments provenant de fermes éloignées. De même, CDN met en cache le contenu qui apparaît sur Internet, permettant aux pages Web de se charger beaucoup plus rapidement. Lorsqu'un utilisateur utilise un CDN pour demander du contenu à un site Web, le CDN récupère le contenu d'un serveur d'origine et conserve une copie du contenu pour les demandes futures. Le contenu mis en cache est conservé dans le cache CDN tant que les utilisateurs continuent d'y accéder. Mise en cache de la base de données La mise en cache de la base de données fait référence aux algorithmes de mise en cache intelligents natifs utilisés par toute base de données pour optimiser les lectures et les écritures. Le cache, dans ce cas, peut résider dans plusieurs zones, notamment la base de données, l'application ou en tant que couche autonome. La mise en cache de base de données peut être utilisée avec tous les types de magasins de données, y compris les bases de données NoSQL ainsi que les bases de données relationnelles telles que SQL Server - MySQL ou MariaDB, etc. Elle fonctionne également bien avec de nombreuses plateformes de données telles qu'AWS et Microsoft Azure. Mise en cache du navigateur ou mise en cache côté client Les navigateurs ou les clients stockent les actifs statiques en fonction des en-têtes d'expiration du cache. Les en-têtes de cache HTTP spécifient la durée pendant laquelle le navigateur peut répondre aux réponses de cache suivantes pour le contenu Web demandé. De plus, les navigateurs peuvent mettre en cache la réponse aux requêtes GET pour éviter les appels de données inutiles. Mise en cache côté serveur La mise en cache du serveur est le mécanisme de mise en cache le plus connu et le plus utilisé dans lequel les données sont mises en cache dans une application serveur. Ici, les choses dépendent beaucoup des besoins de l'entreprise, il est hautement optimisé pour les applications avec moins d'utilisateurs simultanés. La mise en cache Web côté serveur implique souvent l'utilisation d'un proxy Web pour conserver les réponses Web des serveurs Web devant lesquels il réside, ce qui réduit considérablement leur charge et leur latence. Ces caches sont implémentés par les administrateurs du site et agissent comme un agent intermédiaire entre le navigateur et les serveurs d'origine. Une autre forme de mise en cache côté serveur consiste à utiliser les magasins clé-valeur tels que Memcached et Redis. En revanche, pour inverser les proxys, qui mettent simplement en cache la réponse HTTP à une requête HTTP spécifique, tout contenu Web nécessaire au développeur de l'application peut être mis en cache à l'aide d'un stockage d'objets clé/valeur. Le contenu Web est souvent extrait à l'aide d'un code d'application ou d'un cadre d'application qui peut exploiter le stockage de données en mémoire. Un autre avantage de l'utilisation de magasins clé/valeur pour la mise en cache en ligne est qu'ils sont fréquemment utilisés pour stocker des sessions Web et d'autres éléments mis en cache. Cela donne une solution unifiée pour une variété de situations d'application. Pourquoi avons-nous besoin de la mise en cache ? La mise en cache présente plusieurs avantages, comme indiqué ci-dessous : Amélioration des performances des applications Comme nous l'avons vu précédemment, le cache est une couche de stockage de données à haut débit qui stocke un sous-ensemble de données fréquemment consultées et généralement transitoires, de sorte que les demandes futures sont traitées plus rapidement que l'accès à l'emplacement de stockage d'origine. Ainsi, la mise en cache permet une réutilisation efficace des données précédemment consultées ou calculées. Par conséquent, l'opération de lecture/écriture des données est considérablement réduite et contribue à améliorer les performances globales de l'application. Réduire le coût de la base de données Une seule instance de cache peut fournir des centaines de milliers d'opérations d'entrée/sortie par seconde, réduisant ainsi le coût total en réduisant le nombre d'instances de base de données requises. Par conséquent, les économies de coûts peuvent être importantes si les frais de stockage sont par débit. Réduire la charge sur le backend La mise en cache peut réduire efficacement la charge sur le serveur principal et lui éviter un ralentissement des performances, en redirigeant les parties spécifiques de la charge de lecture de la base de données principale vers la couche de mise en cache en mémoire. Cela peut éviter au système de tomber en panne en cas de surcharge ou de pic de trafic. Performances prévisibles Un défi courant avec les applications modernes est lorsqu'il s'agit de gérer les pics d'utilisation des applications. Par exemple - pic sur les applications de médias sociaux lors d'un événement technologique mondial, un match de cricket ou un jour d'élection, ou une vente festive sur un site Web de commerce électronique, etc. Une charge accrue sur l'application pourrait entraîner une latence pour obtenir des données, rendant ainsi la performance ainsi que l'expérience utilisateur imprévisible. Cependant, en utilisant un cache en mémoire à haut débit, nous pouvons atténuer ce problème dans une large mesure. Éliminer les points chauds de la base de données Un petit sous-ensemble de données, tel qu'un profil de célébrité ou un produit populaire, est susceptible d'être récupéré plus fréquemment que le reste dans de nombreuses applications. Cela peut provoquer des hotspots dans votre base de données et nécessiter un surprovisionnement des ressources de la base de données en fonction des exigences de débit pour les données les plus fréquemment utilisées. Le stockage des clés communes en mémoire réduit le besoin de surprovisionnement tout en offrant des performances rapides et prévisibles pour les données les plus fréquemment consultées. Augmenter le débit de lecture (IOPS) En plus de réduire la latence, les systèmes en mémoire fournissent des taux de requête nettement supérieurs à ceux d'une base de données sur disque similaire. Une seule machine de cache secondaire distribuée peut traiter des centaines de milliers de requêtes par seconde. Après avoir discuté des avantages de la mise en cache, plongeons dans les stratégies de mise en cache avec quelques cas d'utilisation réels. Dans cet article, nous nous concentrerons principalement sur les stratégies de mise en cache côté serveur. 5 différents types de stratégies de mise en cache de serveur Cache de côté Dans cette stratégie de cache, le cache est logiquement mis de côté et l'application communique directement avec la base de données ou le cache pour savoir si l'information demandée est présente ou non. Tout d'abord, l'application vérifie avec le cache, si l'information est trouvée, elle lit et renvoie les données, et c'est ce qu'on appelle un sinon si l'information n'est pas trouvée, c'est ce qu'on appelle un , auquel cas, le L'application interroge la base de données pour lire les informations et renvoie les données demandées au client, puis les stocke également dans le cache pour une utilisation future. cache hit cache miss Il est essentiellement bénéfique dans les cas d'utilisation qui nécessitent beaucoup de lecture. Par conséquent, si le serveur de cache est en panne, le système fonctionnera correctement en communiquant directement avec la base de données, mais ce n'est pas une solution à long terme ou fiable en cas de pic de charge ou de pics qui peuvent survenir soudainement. La stratégie d'écriture la plus courante consiste à écrire directement dans la base de données, mais cela peut entraîner une incohérence des données en cas d'écritures fréquentes. Pour faire face à cette situation, les développeurs utilisent souvent un et continuent à servir jusqu'à son expiration. cache avec TTL (Time to Live) Voici un aperçu rapide du cache avec et sans TTL et quand les utiliser : Cache avec TTL Un cache avec TTL est le cache le plus couramment utilisé lorsque les données sont mises à jour fréquemment. Dans de tels cas, vous souhaitez que le cache expire à intervalles réguliers, vous pouvez donc utiliser un cache avec une limite de temps et le cache sera automatiquement supprimé une fois l'intervalle de temps écoulé. Par exemple - sessions de serveur ou tableaux de bord sportifs. Cache sans TTL Un cache sans TTL est utilisé pour les besoins de mise en cache qui n'ont pas besoin d'être mis à jour fréquemment, par exemple, le contenu d'un site Web qui propose des cours. Dans ce cas, le contenu sera mis à jour ou publié peu fréquemment, et il est donc beaucoup plus facile de le mettre en cache sans limite de temps. Cache d'écriture immédiate Comme son nom l'indique, dans cette stratégie, toute nouvelle information est d'abord écrite dans le cache avant la mémoire principale/base de données. Dans ce cas, le cache est logiquement entre l'application et la base de données. Par conséquent, si un client demande des informations, l'application n'a pas besoin de vérifier auprès du cache la disponibilité des informations car le cache contient déjà les informations, et donc, elles sont directement extraites du cache et servies au client. Cependant, cela augmente la latence d'une opération d'écriture. Mais s'il est associé à une autre stratégie de mise en cache appelée cache de lecture, nous pouvons garantir la cohérence des données. Cache de lecture Dans cette stratégie de mise en cache, le cache est aligné sur la base de données de sorte qu'à chaque fois qu'il y a un manque de cache (les données ne sont pas trouvées dans le cache), les données manquantes sont remplies à partir de la base de données et sont renvoyées au client. Comme vous l'avez peut-être deviné, cela fonctionne mieux pour les applications lourdes telles que le même ensemble d'informations est demandé encore et encore. Par exemple, un site Web d'actualités diffuserait les mêmes histoires pendant une journée, encore et encore. L'inconvénient de cette stratégie est que si les données sont demandées pour la première fois, il s'agit toujours d'un manque de cache et, par conséquent, elles seront plus lentes qu'une requête normale. Réécriture Dans cette stratégie de mise en cache, chaque fois qu'il y a une opération d'écriture, l'application écrit les informations dans le cache qui reconnaît immédiatement les modifications et après un certain délai, réécrit les données dans la base de données. Elle est également connue sous le nom de stratégie de mise en cache en écriture différée. C'est une bonne stratégie de mise en cache pour les applications qui sont lourdes sur les opérations d'écriture pour améliorer les performances d'écriture de l'application. Cela peut également aider à gérer les temps d'arrêt modérés de la base de données et les pannes qui peuvent survenir dans les instances. Il peut également bien fonctionner lorsqu'il est associé à un cache de lecture. De plus, cela peut encore réduire la charge de travail d'écriture sur la base de données si le traitement par lots est pris en charge. Cependant, l'inconvénient est qu'en cas de défaillance du cache, les données peuvent être perdues à jamais. Dans la plupart des bases de données relationnelles, le mécanisme de mise en cache en écriture différée est activé par défaut. Écrire autour Dans ce cas, les données sont directement écrites dans la base de données et seules les données lues sont stockées dans le cache. Il peut être combiné avec le cache de lecture et peut être un bon choix dans les situations où les données sont écrites une fois et ne sont lues que quelques fois. Par exemple, lorsqu'il y a un besoin de journaux ou de discussions en temps réel. Conclusion Dans cet article, nous avons discuté de ce qu'est la mise en cache et des différents niveaux de mise en cache dans une application, et pourquoi nous en avons besoin. Ensuite, nous avons également discuté de diverses stratégies de mise en cache pour la mise en cache côté serveur. Cependant, il n'est pas nécessaire que l'une de ces stratégies de mise en cache puisse répondre à vos cas d'utilisation pratiques, mais il est toujours recommandé d'opter pour une combinaison de ces stratégies pour obtenir les meilleurs résultats. Pour un développeur novice, cela peut nécessiter des essais et des erreurs, ou nous pouvons dire, frapper ou manquer pour acquérir une compréhension plus approfondie du concept dans le sens pratique et trouver la meilleure solution pour un cas d'utilisation particulier. C'était tout pour cet article, j'espère que vous l'avez trouvé utile. Faites-moi savoir ce que vous pensez. Vous pouvez me joindre ici : | | LinkedIn Gazouillement GitHub Continue de lire!
