Qu'est-ce que le cache Redis ?
Le cache Redis est une base de données clé-valeur de type journal open source écrite en langage ANSIC, prend en charge le réseau, peut être basée sur la mémoire et persistante, et fournit des API dans plusieurs langues.
Quel est le rôle du cache Redis ?
L'utilisation du cache Redis a grandement amélioré les performances et l'efficacité des applications, notamment dans les requêtes de données. Mais en même temps, cela pose également certains problèmes. Parmi eux, le problème le plus critique est celui de la cohérence des données. À proprement parler, ce problème n’a pas de solution. Si les exigences de cohérence des données sont très élevées, la mise en cache ne peut pas être utilisée.
D'autres problèmes typiques sont la pénétration du cache, l'avalanche de cache et la panne du cache. À l’heure actuelle, l’industrie dispose également de solutions relativement populaires. Cet article n’a pas pour but de résoudre ces trois problèmes de manière plus parfaite, ni de renverser les solutions populaires dans l’industrie. Au lieu de cela, nous démontrerons ces trois phénomènes problématiques à travers des opérations de code réelles. La raison en est qu'il est difficile d'avoir un concept très vivant dans l'esprit simplement en regardant les explications académiques de ces problèmes. Avec des démonstrations de code réelles, nous pouvons approfondir notre compréhension et notre compréhension de ces problèmes.
Pénétration du cache
La pénétration du cache fait référence à l'interrogation de données qui ne doivent pas exister dans une base de données. Le processus normal d'utilisation du cache consiste à peu près à ce que la requête de données effectue d'abord une requête de cache. Si la clé n'existe pas ou si la clé a expiré, interrogez ensuite la base de données et placez l'objet interrogé dans le cache. Si l'objet de requête de base de données est vide, il ne sera pas placé dans le cache.
Flux de code
1. Le paramètre est passé dans l'ID de clé primaire de l'objet
2 Récupérez l'objet du cache en fonction de la clé
<.>3. Si l'objet n'est pas vide, retournez directement 4. Si l'objet est vide, interrogez la base de données 5. Si l'objet interrogé depuis la base de données n'est pas vide, mettez dans le cache (définissez le délai d'expiration) Imaginez Dans ce cas, que se passera-t-il si le paramètre transmis est -1 ? Ce -1 est un objet qui n'existe définitivement pas. La base de données sera interrogée à chaque fois, chaque requête sera vide et le cache ne sera pas exécuté à chaque fois. En cas d'attaque malveillante, cette vulnérabilité peut être exploitée pour faire pression sur la base de données, voire l'écraser. Même si l'UUID est utilisé, il est facile de trouver une KEY inexistante et de mener des attaques. Dans mon travail, l'éditeur utilisera la méthode de mise en cache des valeurs nulles, qui est l'étape 5 de [Code Process]. Si l'objet interrogé dans la base de données est vide, il sera également mis dans le cache, juste le cache défini. Le délai d'expiration est plus court, par exemple fixé à 60 secondes. (Partage vidéo d'apprentissage :tutoriel vidéo Redis)
Avalanche de cache
L'avalanche de cache fait référence à une certaine période de temps Segment, expiration centralisée du cache. L'une des raisons de l'avalanche est que lorsque j'écris cet article, il est presque minuit sur Double 12, et il y aura bientôt une vague d'achats de panique. Cette vague de produits est introduite de manière plus intensive. Mise en cache, en supposant une heure. Puis à une heure du matin, le cache de ce lot de produits a expiré. Les requêtes d'accès à ce lot de produits tombent toutes sur la base de données, ce qui va générer des pics de pression périodiques pour la base de données. Lorsque l'éditeur travaille sur des projets e-commerce, il utilise généralement différentes catégories de produits et les met en cache pour différentes périodes. Produits de la même catégorie, plus un facteur aléatoire. Cela peut étaler autant que possible le délai d'expiration du cache. De plus, le temps de cache des produits dans les catégories populaires sera plus long et le temps de cache des produits dans les catégories impopulaires sera plus court, ce qui peut également économiser les ressources du service de cache. En fait, l'expiration centralisée n'est pas très fatale. L'avalanche de cache la plus fatale se produit lorsqu'un certain nœud du serveur de cache est en panne ou déconnecté du réseau. Parce que l'avalanche de cache naturellement formée doit créer des caches de manière intensive pendant un certain temps, la base de données peut alors résister à la pression. À ce moment-là, la base de données peut également résister à la pression. Ce n'est rien de plus qu'une pression périodique sur la base de données. Le temps d'arrêt du nœud de service de cache exercera une pression imprévisible sur le serveur de base de données et il est très probable que la base de données soit submergée en un instant.Panne du cache
La panne du cache signifie qu'une clé est très chaude et transporte constamment une grande concurrence. Une grande concurrence se concentre sur l'accès à ce point, lorsque la clé expire. la grande concurrence continue traverse le cache et demande directement à la base de données, ce qui revient à percer un trou dans une barrière. Lorsque l'éditeur travaillait sur un projet e-commerce, ce produit est devenu un "hot item". En fait, dans la plupart des cas, il est difficile que ce type d'explosion provoque une pression écrasante sur le serveur de base de données. Rares sont les entreprises qui ont atteint ce niveau. Par conséquent, l’éditeur pragmatique a préparé très tôt les principaux produits afin que le cache n’expire jamais. Même si certains produits deviennent populaires d’eux-mêmes, configurez-les simplement pour qu’ils n’expirent jamais. Pour faire simple, la clé mutex n'est vraiment pas utile. Partage du tutoriel d'apprentissage :Tutoriel sur la base de données Redis
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!