Aujourd'hui, nous plongeons dans le monde du cache. La mise en cache est une arme secrète pour créer des systèmes évolutifs et performants. Il existe de nombreux types de mise en cache, mais dans cet article, nous nous concentrerons sur la mise en cache des objets backend (mise en cache backend). Le maîtriser vous aidera à créer des logiciels performants et fiables. Dans cet article, nous explorerons : Nous explorerons la mise en cache et expliquerons comment elle stocke temporairement les données pour un accès plus rapide. Qu’est-ce que la mise en cache ? : découvrez comment la mise en cache augmente la vitesse, réduit la charge du serveur, améliore l'expérience utilisateur et peut même réduire les coûts. Avantages de la mise en cache : dans cette section, nous aborderons différentes manières d'utiliser le cache. N'oubliez pas qu'il y a des avantages et des inconvénients à chaque approche, alors assurez-vous de choisir le modèle adapté à vos besoins ! Modèle de mise en cache : vous savez désormais comment stocker et récupérer les données mises en cache. Mais comment garantir que vos données mises en cache restent à jour ? Et que se passe-t-il lorsque le cache atteint sa capacité ? Meilleure pratique de mise en cache : Bien que la mise en cache offre de nombreux avantages, il est parfois préférable de l'éviter. La mise en œuvre de la mise en cache dans un mauvais système peut augmenter la complexité et potentiellement même ralentir les performances. Quand ne pas mettre en cache Qu’est-ce que la mise en cache ? Créer une application performante et évolutive consiste à éliminer les goulots d'étranglement et à rendre le système plus efficace. Les bases de données entravent souvent les performances du système en raison de leurs exigences de stockage et de traitement. Cela en fait un élément coûteux car ils doivent être souvent étendus. Heureusement, il existe un composant qui peut aider à alléger l'utilisation des ressources de la base de données tout en améliorant la vitesse de récupération des données : ce composant est appelé . cache Le cache est un stockage temporaire conçu pour une écriture et une lecture rapides des données. Il utilise un stockage mémoire à faible latence et des structures de données optimisées pour des opérations rapides. Il y a de fortes chances que vous ayez déjà utilisé Redis ou Memcached, ou au moins entendu leurs noms. Ce sont deux des systèmes de mise en cache distribués les plus populaires pour les services backend. Redis peut même faire office de base de données principale, mais c'est un sujet pour un autre article ! Avantages de la mise en cache Le principal avantage de la mise en cache est sa rapidité. La lecture de données depuis un cache est nettement plus rapide que leur récupération depuis une base de données (comme SQL ou Mongo). Cette vitesse provient des caches utilisant des structures de données de dictionnaire (ou HashMap) pour des opérations rapides et stockant les données dans une mémoire à haute vitesse plutôt que sur disque. Deuxièmement, la mise en cache réduit la charge sur votre base de données. Cela permet aux applications d'obtenir les données dont elles ont besoin à partir du cache au lieu d'accéder constamment à la base de données. Cela réduit considérablement l'utilisation des ressources matérielles ; au lieu de rechercher des données sur le disque, votre système y accède simplement à partir d'une mémoire rapide. Ces avantages améliorent directement l’expérience utilisateur et peuvent conduire à des économies. Votre application répond beaucoup plus rapidement, créant ainsi une expérience plus fluide et plus satisfaisante pour les utilisateurs. La mise en cache réduit les coûts d’infrastructure. Même si un système distribué comme Redis nécessite ses propres ressources, les économies globales sont souvent importantes. Votre application accède aux données plus efficacement, ce qui vous permet potentiellement de réduire la taille de votre base de données. Cependant, cela s'accompagne d'un compromis : si votre système de cache tombe en panne, assurez-vous que votre base de données est prête à gérer la charge accrue. Modèles de cache Maintenant que vous comprenez le pouvoir de la mise en cache, examinons les meilleures façons de l'utiliser ! Dans cette section, nous explorerons deux catégories essentielles de modèles : et . Ces modèles fournissent des stratégies pour gérer les mises à jour du cache et gérer les situations dans lesquelles les données dont vous avez besoin ne sont pas encore dans le cache. les modèles d'écriture de cache les modèles d'échec de cache Modèles d'écriture Les modèles d'écriture dictent la manière dont votre application interagit à la fois avec le cache et votre base de données. Examinons trois stratégies courantes : , et . Chacun offre des avantages et des compromis uniques : Write-back Write-through Write-around Répondre Comment ça fonctionne: Votre application interagit uniquement avec le cache. Le cache confirme l'écriture instantanément. Un processus en arrière-plan copie ensuite les données nouvellement écrites dans la base de données. les applications gourmandes en écriture où la vitesse est essentielle et où une certaine incohérence est acceptable pour des raisons de performances. Les exemples incluent les applications de métriques et d’analyse. Idéal pour : Avantages : les données sont toujours dans le cache pour un accès rapide, contournant entièrement la base de données. Lectures plus rapides : votre application n'attend pas les écritures de la base de données, ce qui entraîne des temps de réponse plus rapides. Écritures plus rapides : les écritures par lots réduisent la charge de la base de données et peuvent potentiellement prolonger la durée de vie de votre matériel de base de données. Moins de pression sur la base de données : Désavantages: si le cache échoue avant que les données ne soient enregistrées dans la base de données, des informations peuvent être perdues. Redis atténue ce risque grâce au stockage persistant, mais cela ajoute de la complexité. Risque de perte de données : vous aurez besoin d'un middleware pour garantir que le cache et la base de données restent finalement synchronisés. Complexité accrue : toutes les écritures sont d'abord transférées dans le cache, même si les données ne sont pas fréquemment lues. Cela peut entraîner une consommation de stockage élevée. Potentiel d'utilisation élevée du cache : Écrire via Comment ça fonctionne: Votre application écrit simultanément dans le cache et dans la base de données. Pour réduire le temps d'attente, vous pouvez écrire dans le cache de manière asynchrone. Cela permet à votre application de signaler les écritures réussies avant que l'opération de cache ne soit complètement terminée. Avantages : comme pour l'écriture différée, les données sont toujours dans le cache, éliminant ainsi le besoin de lectures dans la base de données. Lectures plus rapides : votre application ne confirme une écriture qu'après son enregistrement dans la base de données, garantissant ainsi la persistance des données même si un crash survient immédiatement après. Fiabilité : Désavantages: par rapport à l'écriture différée, cette stratégie entraîne une certaine surcharge car l'application attend que la base de données et le cache écrivent. Les écritures asynchrones améliorent cela, mais rappelez-vous qu'il y a toujours le temps d'attente de la base de données. Écritures plus lentes : toutes les écritures sont transférées dans le cache, consommant potentiellement de l'espace de stockage même si les données ne sont pas fréquemment consultées. Utilisation élevée du cache : Écrire autour Avec Write-Around, votre application écrit les données directement dans la base de données, en contournant le cache pendant le processus d'écriture. Pour remplir le cache, il utilise une stratégie appelée : modèle cache-aside l'application vérifie le cache. La demande de lecture arrive : si les données ne sont pas trouvées dans le cache, l'application les récupère dans la base de données, puis les stocke dans le cache pour une utilisation ultérieure. Manque de cache : Avantages : les données sont écrites directement dans la base de données, garantissant ainsi leur cohérence. Écritures fiables : seules les données fréquemment consultées sont mises en cache, réduisant ainsi la consommation de mémoire. Utilisation efficace du cache : Désavantages: si les données ne sont pas dans le cache, l'application doit les récupérer dans la base de données, ce qui ajoute un aller-retour par rapport aux politiques où le cache est toujours pré-rempli. Latence de lecture plus élevée (dans certains cas) : Modèle d'échec du cache Un échec de cache se produit lorsque les données dont votre application a besoin ne sont pas trouvées dans le cache. Voici deux stratégies courantes pour résoudre ce problème : Cache-mis à part L'application vérifie le cache. En cas d'échec, il récupère les données de la base de données, puis met à jour le cache. L’application se charge de gérer le cache. Point clé : L’utilisation d’un modèle Cache-Aside signifie que votre application gérera le cache. Cette approche est la plus courante à utiliser car elle est simple et ne nécessite pas de développement ailleurs que dans l'application. Lire à travers L'application fait une requête sans connaître le cache. Un mécanisme spécialisé vérifie le cache et récupère les données de la base de données si nécessaire. Le cache est mis à jour de manière transparente. Les modèles de lecture directe réduisent la complexité des applications, mais augmentent la complexité de l'infrastructure. Cela permet plutôt de décharger la ressource de l’application vers le middleware. Dans l’ensemble, le modèle d’écriture avec cache-aside est le plus couramment utilisé en raison de sa facilité de mise en œuvre. Cependant, je recommande également d'inclure le modèle d'écriture directe si vous disposez de données qui seront utilisées immédiatement après leur mise en cache. Cela apportera un léger avantage aux performances de lecture. Meilleures pratiques de mise en cache Dans cette section, nous explorerons les meilleures pratiques d'utilisation d'un cache. Le respect de ces pratiques garantira que votre cache conserve des données fraîches et gère efficacement son stockage. Invalidation du cache Imaginez que vous avez stocké des données dans le cache, puis que la base de données est mise à jour. Cela fait que les données du cache diffèrent de la version de la base de données. Nous appelons ce type de données en cache « périmées ». Sans technique d'invalidation du cache, vos données mises en cache pourraient rester obsolètes après les mises à jour de la base de données. Pour conserver les données à jour, vous pouvez utiliser les techniques suivantes : lorsque vous mettez à jour des données dans la base de données, mettez également à jour l'entrée de cache correspondante. Les modèles d'écriture directe et de réécriture gèrent cela de manière inhérente, mais l'écriture indirecte/la mise en cache nécessite une suppression explicite des données mises en cache. Cette stratégie empêche votre application de récupérer des données obsolètes. Invalidation du cache lors de la mise à jour : TTL est une politique que vous pouvez définir lors du stockage des données dans le cache. Avec TTL, les données sont automatiquement supprimées après une heure spécifiée. Cela permet d'effacer les données inutilisées et fournit une sécurité contre les données obsolètes en cas d'invalidations manquées. Time To Live (TTL) : Politiques de remplacement du cache Si vous mettez en cache une grande quantité de données, votre stockage en cache pourrait se remplir. Les systèmes de cache utilisent généralement de la mémoire, qui est souvent plus petite que le stockage de votre base de données principale. Lorsque le cache est plein, il doit supprimer certaines données pour libérer de l'espace. Les politiques de remplacement du cache déterminent les données à supprimer : cette stratégie commune supprime les données qui n'ont pas été utilisées (lues ou écrites) depuis le plus longtemps. LRU convient à la plupart des cas d’utilisation réels. Les moins récemment utilisées (LRU) : similaire à LRU, mais se concentre sur la fréquence d'accès. Les données nouvellement écrites peuvent être expulsées, pensez donc à ajouter une période de préchauffage pendant laquelle les données ne peuvent pas être supprimées. Les moins fréquemment utilisés (LFU) : D'autres politiques de remplacement comme le FIFO (First-In, First-Out), le remplacement aléatoire, etc. existent mais sont moins courantes. Quand ne pas mettre en cache Avant de plonger dans la mise en œuvre du cache, il est important de savoir quand cela n’est peut-être la meilleure solution. La mise en cache améliore souvent la vitesse et réduit la charge de la base de données, mais cela peut ne pas avoir de sens si : pas si votre application a un faible trafic et que le temps de réponse est toujours acceptable, vous n'avez probablement pas encore besoin de mise en cache. L'ajout d'un cache augmente la complexité. Il est donc préférable de l'implémenter lorsque vous êtes confronté à des goulots d'étranglement en termes de performances ou que vous anticipez une augmentation significative du trafic. Faible trafic : la mise en cache est plus avantageuse dans les applications gourmandes en lecture. Cela signifie que les données de votre base de données sont rarement mises à jour ou lues plusieurs fois entre les mises à jour. Si votre application a un volume d'écritures élevé, la mise en cache peut potentiellement ajouter une surcharge et ralentir les choses. Votre système est gourmand en écriture : Points à retenir Dans cet article, nous avons couvert les bases de la mise en cache et comment l'utiliser efficacement. Voici un récapitulatif des points clés : assurez-vous que votre système est lourd en lecture et nécessite les offres de mise en cache de réduction de latence. Confirmez le besoin : sélectionnez des modèles d'écriture de cache et d'échec de cache qui correspondent à la manière dont votre application utilise les données. Choisissez judicieusement les modèles : mettez en œuvre des stratégies d'invalidation du cache pour éviter de diffuser des données obsolètes. Fraîcheur des données : choisissez une politique de remplacement du cache (comme LRU) pour gérer les suppressions lorsque le cache atteint sa capacité. Gérer la politique de remplacement : Les références https://gist.github.com/jboner/2841832 https://www.bytesizedpieces.com/posts/cache-types https://www.techtarget.com/searchstorage/definition/cache https://www.youtube.com/watch?v=dGAgxozNWFE
