L’utilisation du cache Redis améliore considérablement les performances et l’efficacité des applications, en particulier pour les requêtes de données. Mais en même temps, cela apporte aussi quelques problèmes. Parmi eux, le problème le plus important est la cohérence des données, qui est strictement insoluble. Si la cohérence des données est requise, alors 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 défaillance du cache. Actuellement, il existe aussi des solutions plus populaires dans le secteur. Cet article ne vise pas à résoudre ces trois problèmes plus parfaitement, ni à subvertir les solutions populaires dans l’industrie. À la place, nous allons démontrer ces trois phénomènes problématiques à partir de l’opération réelle du code. La raison de faire cela est qu’il est difficile d’avoir un concept très vivant en tête simplement en regardant l’explication académique de ces problèmes, et avec de véritables démonstrations de code, vous pouvez approfondir votre compréhension et votre 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 n’existent pas dans une base de données. Si la clé n’existe pas ou si la clé a expiré, la base de données est interrogée et les objets interrogés sont placés dans le cache. Si l’objet de requête de la base de données est vide, il n’est pas mis en cache.
Flux de code
- le paramètre passe l’identifiant de clé primaire de l’objet
- Récupérez l’objet du cache en fonction de la clé
- Si l’objet n’est pas vide, il retourne directement
- Si l’objet est vide, effectuez une requête dans la base de données
- Si l’objet interrogé depuis la base de données n’est pas vide, mettez-le dans le cache (définissez le temps d’expiration). Imaginez cette situation, que se passerait-il si le paramètre passé était -1 ? Ce -1 est un objet qui ne doit pas exister. La base de données sera interrogée à chaque fois, chaque requête sera vide, et elle ne sera pas mise en cache à chaque fois. En cas d’attaque malveillante, cette vulnérabilité peut être exploitée pour exercer une pression sur la base de données, voire la submerger. Même si l’UUID est utilisé, il est facile de trouver une CLÉ inexistante et d’attaquer.
Dans mon travail, j’utilise la méthode de mise en cache des valeurs nulles, c’est-à-dire l’étape 5 du [processus de code], si l’objet interrogé depuis la base de données est vide, il est également mis dans le cache, mais le temps d’expiration défini est court, comme en le fixant à 60 secondes.
Avalanche de caches
Avalanche de cache fait référence à l’expiration de l’ensemble de cache pendant une certaine période.
L’une des raisons de l’avalanche, par exemple, c’est qu’en écrivant cet article, elle sera bientôt à zéro heure le douzième jour, et qu’il y aura bientôt une vague d’achats en rush. Puis à une heure du matin, la réserve de ce lot de marchandises expirera. La requête d’accès pour ce lot de marchandises revient à la base de données, et pour celle-ci, il y aura des pics de pression périodiques.
Lorsque Xiaobian réalise des projets de commerce électronique, il adopte généralement différentes catégories de biens et met en cache différents cycles. Des biens dans la même catégorie, plus un facteur aléatoire. De cette façon, le temps d’expiration du cache peut être dispersé autant que possible, et le temps de cache des produits dans les catégories populaires est plus long, et celui des produits dans les catégories impopulaires est plus court, ce qui peut également économiser les ressources du service de mise en cache.
En fait, l’expiration centralisée n’est pas très fatale, et l’avalanche de cache la plus fatale est qu’un nœud du serveur de cache tombe en panne ou se déconnecte. Parce que l’avalanche de cache qui se produit naturellement doit être créée dans un certain laps de temps, la base de données peut supporter la pression, et à ce moment-là, elle peut aussi résister à cette pression. Ce n’est rien d’autre qu’une pression périodique sur la base de données. Le temps d’arrêt du nœud de service cache exerce une pression imprévisible sur le serveur de base de données, et il est probable qu’il submerge la base de données instantanément.
Décomposition du cache
La rupture du cache désigne une clé très chaude, transportant constamment une grande concurrence ; la grande concurrence se concentre sur l’accès à ce point, et lorsque cette clé échoue, la grande concurrence continue perce le cache et demande directement la base de données, comme en forant un trou dans une barrière.
Lorsque Xiaobian menait des projets de commerce électronique, il a fait de ce produit un « succès ».
En fait, dans la plupart des cas, ce type d’explosion est difficile à exercer une pression écrasante sur le serveur de base de données. Peu d’entreprises ont atteint ce niveau. Par conséquent, l’éditeur pragmatique s’est préparé tôt pour les produits principaux, afin que le cache n’expire jamais. Même si certains produits fermentent en bouffées, ils peuvent être définis comme ne jamais périmant.
La route principale est simple, et la serrure de rejet mutuelle à clé mutex n’est vraiment pas utilisée.
|
Publié sur 19/11/2019 09:55:04
|
|
|
|
