Maison > Article > base de données > Comment améliorer le taux de réussite du cache Redis
Hit : les données requises peuvent être obtenues directement via le cache.
Manqué : les données souhaitées ne peuvent pas être obtenues directement via le cache et la base de données doit être à nouveau interrogée ou d'autres opérations doivent être effectuées. La raison pourrait être qu'il n'existe tout simplement pas dans le cache ou que le cache a expiré.
De manière générale, plus le taux de réussite du cache est élevé, plus les avantages de l'utilisation du cache sont élevés, meilleures sont les performances de l'application (temps de réponse plus court, débit plus élevé) et plus la capacité à résister à la concurrence est forte.
On peut voir que dans un système Internet à haute concurrence, le taux de réussite du cache est un indicateur crucial.
Dans memcached, exécutez la commande state pour afficher les informations d'état du service memcached, où cmd_get représente le nombre total de get, get_hits représente le nombre total de hits, taux de réussite = get_hits/cmd_get.
Bien sûr, nous pouvons également surveiller l'ensemble du cluster memcached via certains outils tiers open source, et l'affichage sera plus intuitif. Les exemples typiques incluent : zabbix, MemAdmin, etc.
Comme le montre la figure : statistiques de surveillance par MemAdmin du taux de réussite du service memcached
De même, vous pouvez exécuter des informations dans redis Utilisez la commande pour afficher les informations d'état du service Redis, où keyspace_hits est le nombre total d'accès, keyspace_misses est le nombre total d'échecs et taux de réussite = keyspace_hits/(keyspace_hits+keyspace_misses).
L'outil open source Redis-star peut visualiser les informations relatives au service Redis dans un graphique. En même temps, zabbix fournit également des plug-ins associés pour surveiller les services Redis.
Dans le chapitre précédent, nous avons mentionné l'importance du taux de réussite du cache. Analysons plusieurs facteurs qui affectent le taux de réussite du cache.
Le cache convient aux scénarios commerciaux avec "plus de lectures et moins d'écritures". Au contraire, l'utilisation du cache n'a en réalité aucune importance. super. Le taux de réussite sera très faible.
Les besoins de l'entreprise déterminent les exigences de rapidité, ce qui affecte directement le délai d'expiration du cache et la stratégie de mise à jour. Plus l’exigence de rapidité est faible, plus elle est adaptée à la mise en cache. Dans le cas d’une même clé et d’un même nombre de requêtes, plus le temps de cache est long, plus le taux de réussite sera élevé.
Le cache convient à la plupart des scénarios commerciaux d'applications Internet.
Généralement, plus la granularité du cache est faible, plus le taux de réussite est élevé. Un exemple pratique :
Lors de la mise en cache d'un seul objet (par exemple : les informations d'un seul utilisateur), il suffit de mettre à jour le cache ou de supprimer le cache lorsque les données correspondant à l'objet changent. Lors de la mise en cache d'une collection (par exemple : toutes les données utilisateur), lorsque les données correspondant à un objet changent, le cache doit être mis à jour ou supprimé.
Il existe une autre situation, en supposant que d'autres endroits doivent également obtenir les données correspondant à l'objet (par exemple, d'autres endroits doivent également obtenir des informations sur les utilisateurs individuels), si le cache est un seul objet, vous pouvez frapper directement le cache sinon, il ne peut pas frapper directement. Ceci est plus flexible et le taux de réussite du cache sera plus élevé.
De plus, la politique de mise à jour/expiration du cache affecte également directement le taux de réussite du cache. Lorsque les données changent, la mise à jour directe de la valeur mise en cache aura un taux de réussite plus élevé que la suppression du cache (ou le fait de laisser le cache expirer). Bien entendu, la complexité du système sera également plus élevée.
La capacité du cache est limitée, ce qui peut facilement provoquer une défaillance et une élimination du cache (la plupart des frameworks ou middleware de cache utilisent actuellement l'algorithme LRU). Dans le même temps, le choix de la technologie de mise en cache est également crucial. Par exemple, l'utilisation d'un cache local intégré à l'application est plus susceptible de provoquer un goulot d'étranglement sur une seule machine, tandis que l'utilisation d'un cache distribué est facile à étendre. Il est donc nécessaire de planifier la capacité du système et de déterminer si elle est évolutive. De plus, l’efficacité et la stabilité des différents frameworks ou middleware de mise en cache sont également différentes.
Lorsqu'un nœud de cache tombe en panne, il est nécessaire d'éviter l'invalidation du cache et de minimiser l'impact. Cette situation particulière doit également être prise en compte par l'architecte. Une approche typique dans l'industrie consiste à utiliser un algorithme de hachage cohérent ou une redondance de nœuds.
Certains amis peuvent avoir ce malentendu : étant donné que les besoins de l'entreprise ont des exigences élevées en matière d'actualité des données et que le temps de cache affectera le taux de réussite du cache, le système ne doit pas utiliser le cache. En fait, cela ignore un facteur important : la concurrence. De manière générale, avec la même durée de cache et la même clé, plus la concurrence est élevée, plus les revenus du cache seront élevés, même si la durée du cache est courte.
Du point de vue d'un architecte, l'application doit autant que possible obtenir des données directement via le cache et éviter l'invalidation du cache. Cela teste également les capacités de l'architecte et nécessite une réflexion approfondie et des compromis sur divers aspects tels que les exigences métier, la granularité du cache, la stratégie de cache et la sélection technologique. Essayez de vous concentrer autant que possible sur les services chauds qui sont fréquemment consultés et ont de faibles exigences de rapidité, et améliorez le taux de réussite grâce au préchargement du cache (réchauffement), à l'augmentation de la capacité de stockage, à l'ajustement de la granularité du cache et à la mise à jour du cache.
Pour les applications avec une rapidité élevée (ou un espace de cache limité), une grande étendue de contenu (ou un accès très aléatoire) et un faible volume d'accès, le taux de réussite du cache peut être très faible pendant une longue période. Le cache a expiré. avant même d’y avoir accédé.
Pour plus d'articles techniques liés à Redis, veuillez visiter la colonne Tutoriel Redis pour apprendre !
Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!