Q : Quel type de cache constitue un bon cache ?
Un cache qui résout un problème est un bon cache. Cette phrase est tout simplement absurde, équivalente à chat blanc, chat noir, et celui qui attrape les souris est un bon chat.
Donc, en vue de résoudre le problème, quel cache est le meilleur cache ? Ma réponse à cette question est la suivante : un cache avec un taux de réussite élevé est un bon cache.
Dans l'hypothèse de résoudre le problème, un cache avec un taux de réussite élevé peut nécessiter moins d'investissement matériel qu'un cache avec un faible taux de réussite. Dans le même temps, le nombre de caches peut être inférieur au nombre de caches avec un faible taux de réussite. De cette façon, la vitesse d'adressage sera certainement plus rapide. Un cache avec un taux de réussite élevé est donc un bon cache.
Taux de réussite du cache
Une fois qu'une entité mise en cache est placée dans le cache, si elle n'a pas été utilisée une seule fois par le monde extérieur pendant que l'entité est mise en cache (pendant le cycle de vie de l'entité mise en cache), le taux de réussite de l'entité mise en cache est de 0. Plus cette entité est demandée plusieurs fois, plus son taux de réussite dans le cache est élevé.
Ce qui est mentionné ci-dessus est le taux de réussite d'une entité dans le cache. Pour le cache dans son ensemble, son taux de réussite est le diagramme de distribution du taux de réussite de chaque individu mis en cache ci-dessus.
Pour la mise en cache : les individus les plus couramment utilisés ne représentent généralement qu’une très petite partie du total. Les moins fréquemment utilisés représentent une part importante de l’ensemble.
Nous voyons donc souvent des données comme celles-ci :
Sur les 10 000 éléments mis en cache, 100 sont utilisés fréquemment, presque toutes les minutes. 2000 données, demandées une fois par heure. 3 000 données sont demandées une fois par jour, et les données restantes n'ont pas été utilisées une seule fois après avoir été placées dans le cache.
De nos jours, le matériel se développe rapidement. Si nous n'avons besoin que de mettre en cache 10 000 données, nous pouvons mettre complètement les 10 000 données dans le cache, qu'elles soient utilisées ou non. De cette façon, tant que nous recherchons des données, nous les aurons certainement. données dans le cache. Il n'est pas nécessaire d'effectuer des opérations supplémentaires ou de faire des requêtes à la base de données.
Cependant : le matériel évolue rapidement, tout comme la quantité de données. Pour un petit site Web, si 10 000 données sont mises en cache, elles seront toutes mises en cache. Cependant, les grands sites Web contiennent au moins des millions de données ou de données de niveau T. Évidemment, toutes ces données ne peuvent pas être mises en cache. À l’heure actuelle, il est très important de concevoir une solution de mise en cache raisonnable et d’améliorer le taux de réussite du cache. Et c'est nécessaire.
Quelques méthodes courantes pour améliorer le taux de réussite du cache
D'un point de vue purement technique, nous enregistrons uniquement le nombre de requêtes des utilisateurs par unité de temps et mettons en cache les données les plus couramment utilisées sur la base de ces informations.
Mais le plus souvent, nous améliorons le taux de réussite du cache en fonction de la logique métier. Par exemple : l'année dernière et le blog publié l'année dernière, les demandes de navigation pour ce type d'article étaient généralement au moins quelques fois par jour. Ne doit généralement pas être mis en cache en mémoire.
Pour un autre exemple, une publication avec de nombreuses réponses sera généralement vue par plus de personnes qu'une publication avec moins de réponses.
Nous devons utiliser la logique ci-dessus et fournir un algorithme de mise en cache basé sur notre logique métier réelle pour améliorer le taux de réussite du cache. Mettons en cache les données appropriées, plutôt que toutes les données, comme notre matériel le permet.
Un exemple négatif est le suivant : quoi qu'il en soit, sur un grand site de blog, lorsqu'un article est demandé par un utilisateur, il s'avère qu'il n'est pas dans le cache mémoire, il est donc lu dans la base de données puis jeté dans le cache.
Vous savez, il y a beaucoup de robots d'exploration maintenant. En outre, pour les sites conviviaux pour les moteurs de recherche tels que les blogs, la majeure partie de la pression d'accès provient des moteurs de recherche. Ces visites durent généralement une heure ou une journée, avec seulement quelques ou même une seule demande pour un article donné, puis plus jamais. Le taux de réussite de la méthode de mise en cache ci-dessus sera très faible.
Quelqu'un peut demander ici, Guo Hongjun, puisque vous ne me suggérez pas de mettre en cache le contenu de ces blogs, mais comment puis-je améliorer les performances de mon site. Je dois au moins m'assurer que mon site de blog ne sera pas trop lent à répondre ? aux demandes des utilisateurs.
Il existe de nombreuses solutions à ce problème. L'une des méthodes les plus simples consiste à transformer ces blogs en pages HTML statiques, qui constituent le cache du système de fichiers. En raison du disque dur, le système de fichiers peut être simplement compris comme étant extensible à l'infini. afin que de nombreux contenus avec un faible taux de réussite soient mis en cache.
Si votre page nécessite un jugement logique dynamique, vous pouvez mettre en cache les données dans des fichiers XML, puis le segment de serveur intègre ces fichiers XML ou inclut des fichiers. C'est aussi une bonne approche.
Après avoir évoqué tant de problèmes concernant le taux de réussite du cache, résumons brièvement les points de vue sur le taux de réussite du cache :
Les petits sites Web peuvent mettre en cache toutes les données, et généralement la pression ne sera pas grande, de sorte que les problèmes de taux de réussite du cache peuvent être ignorés.
Les grands services ne peuvent pas mettre en cache toutes les données, mais seulement une partie des données. À ce stade, l'architecte doit concevoir une méthode de mise en cache adaptée à la logique métier afin d'améliorer autant que possible le taux de réussite du cache.
La plupart des méthodes permettant d'améliorer le taux de réussite sont liées à la logique métier et nécessitent une analyse détaillée de problèmes spécifiques. Pour les données qui ne peuvent pas être mises en cache en mémoire, le moyen le plus simple d'améliorer les performances consiste à utiliser la mise en cache de fichiers.
La mise en cache de fichiers peut mettre en cache l'intégralité du contenu dans un fichier statique ; elle peut également mettre en cache une zone de la page entière dans un fichier, puis l'inclure ; elle peut également sérialiser une entité dans un fichier XML pour la mise en cache ;
Examinons quelques autres aspects moins importants de la mise en cache :
Activités du cycle de vie du cache
Le contenu qui n’expire jamais ou qui change pour toujours ne doit pas être placé dans le cache. Le cache est un stockage temporaire et non permanent, son cycle de vie est donc limité.
À son tour, il peut passer par les activités suivantes :
Entrez dans le cache. (Lorsque vous entrez dans le cache, vous devrez peut-être spécifier sa politique d'expiration future. Si elle n'est pas spécifiée, vous devez utiliser la politique d'expiration par défaut du système)
Récupérez-le à partir du cache. Notez que les problèmes de sécurité des threads doivent être résolus à ce stade.
Lors de la mise à jour du cache, notez que vous devez également prendre en compte les problèmes de sécurité des threads lorsque vous quittez le cache. Il peut s'agir d'une requête externe, ou le cache peut la vider en fonction de la stratégie d'expiration.
Politique d'expiration du cache
En général, je demanderais quelles stratégies d'expiration du cache avez-vous rencontrées dans les caches avec lesquels vous êtes entré en contact ?
Les stratégies d'expiration les plus courantes sont les suivantes :
S'il n'a pas été demandé depuis longtemps, il expirera. La fonction la plus typique est la fonction Section fournie par ASP et ASP.net. En fait, c'est un cache.
Le cache qui repose sur les modifications de fichiers expirera une fois le fichier modifié, généralement le Web.config du site WEB. Une fois le fichier modifié, non seulement le cache sera redémarré, mais le processus IIS effectuera également une libération.
Sur cette base, vous pouvez voir des politiques d'expiration du cache pour de nombreuses dépendances. Par exemple, une stratégie d'expiration du cache qui s'appuie sur la base de données.
Bien sûr, il peut y avoir des stratégies d'expiration plus complexes dans la logique métier. Dans la nouvelle version du forum du système de points CSDN, le cache de liste de publications l'effacera à 550 éléments de données lorsque le cache de données de liste atteint 600.
Un autre exemple est que le cache des nouveaux messages du forum basés sur des points expire lorsqu'aucune liste ne fait référence à la publication, et que la publication expire.
Problème de synchronisation du cache
L'utilisation du cache signifie que plusieurs copies des mêmes données peuvent coexister. Si votre code ne prend pas en compte une certaine situation, les deux données seront incohérentes. C’est à ce moment-là que des problèmes surviendront.
La solution est simple. Réfléchissez bien à votre logique métier et aux situations de déclenchement de code, et ne laissez aucun domaine qui n'a pas touché le fond.
Des méthodes simples peuvent rendre la logique de votre code très complexe.
C’est pourquoi certaines personnes recommandent de ne pas utiliser la mise en cache lorsque cela n’est pas nécessaire. Une fois que vous commencez à utiliser la mise en cache, vous devez être prêt à ajouter beaucoup de code pour gérer la synchronisation des données.
Initialiser et remplir les données du cache
Parfois, une fois le cache initialisé, certaines données doivent être pré-remplies dans le cache. Il s'agit de l'opération d'initialisation des données mises en cache.
Les problèmes suivants doivent être pris en compte lors de l'opération d'initialisation des données mises en cache :
Combien de temps faut-il pour s'initialiser ? Généralement, s'il s'agit d'un site, nous pouvons gérer ce travail d'initialisation dans Application_OnStart de Global.asa. L'initialisation ne peut généralement pas prendre trop de temps. À ce stade, notre capacité d'optimisation du code est testée.
Lors de l'initialisation, les données sont généralement importées par lots, au lieu de traiter une donnée à la fois lors d'une utilisation normale.
Résumer:
Cet article présente certains de mes points de vue sur la mise en cache sans entrer dans les détails des technologies de mise en cache spécifiques. J'espère qu'à travers la description de cet article, les personnes qui connaissent uniquement l'utilisation de la mise en cache mais ne comprennent pas l'idée de la mise en cache pourront avoir une compréhension préliminaire.
http://blog.csdn.net/ghj1976/archive/2007/09/01/1768676.aspx