Comprendre l'avalanche de cache Redis, la panne du cache et la pénétration du cache dans un seul article-Redis-php.cn

Cet article vous apporte des connaissances pertinentes sur Redis, qui présente principalement le contenu pertinent sur l'avalanche de cache, la panne de cache et la pénétration du cache. J'espère qu'il sera utile à tout le monde.

Comprendre l'avalanche de cache Redis, la panne du cache et la pénétration du cache dans un seul article

Apprentissage recommandé : Tutoriel vidéo Redis

Concernant les problèmes à haute fréquence de Redis, l'avalanche de cache, la panne de cache et la pénétration du cache doivent être indispensables. Je pense que tout le monde s'est vu poser des questions similaires lors des entretiens. Pourquoi ces questions sont-elles si populaires ? Car lorsque nous utilisons le cache Redis, ces problèmes sont faciles à rencontrer. Voyons ensuite comment ces problèmes surviennent et quelles sont les solutions correspondantes.

Avalanche de cache

Tout d'abord, jetons un coup d'œil à l'avalanche de cache Le concept d'avalanche de cache est le suivant : un grand nombre de requêtes ne sont pas traitées dans le cache Redis, ce qui entraîne un afflux de requêtes dans la base de données, puis la pression sur. la base de données augmente considérablement.

Les raisons de l'avalanche de cache peuvent être résumées en 2 raisons :

Une grande quantité de données dans le cache expire en même temps, donc un grand nombre de requêtes sont envoyées à la base de données à ce moment-là.
L'instance de cache Redis échoue et ne peut pas gérer un grand nombre de requêtes, ce qui entraîne également le transfert des requêtes vers la base de données.

Regardons le premier scénario : une grande quantité de données dans le cache expire en même temps.

Une grande quantité de données dans le cache a expiré en même temps

Combiné avec la légende, cela signifie qu'une grande quantité de données a expiré en même temps, et puis il y a eu de nombreuses demandes de lecture des données à ce moment-là. Bien entendu, une avalanche de cache se produira, provoquant une augmentation spectaculaire de la pression sur la base de données.

Solution pour qu'une grande quantité de données expire en même temps

Pour faire face au problème d'une grande quantité de données qui expire en même temps, il existe généralement deux solutions :

Augmenter le nombre aléatoire temps dans le paramètre d'expiration des données : c'est-à-dire que lorsque vous utilisez la commande expire pour définir le délai d'expiration des données, ajoutez une heure aléatoire, par exemple, les données a expirent dans 5 minutes et 10 à 120 secondes sont ajoutées de manière aléatoire aux 5 minutes. Cela évite que de grandes quantités de données n’expirent en même temps.
Dégradation du service : c'est-à-dire lorsqu'une avalanche de cache se produit, (1) si l'accès ne concerne pas les données de base, lorsqu'il n'y a pas d'accès au cache, la base de données n'ira pas à la base de données et aux informations prédéfinies, telles que les valeurs nulles ou des messages d'erreur, seront renvoyés directement ; (2) Lors de l'accès aux données de base et que le cache manque, la requête de base de données est autorisée. De cette manière, les demandes qui ne sont pas des données de base seront rejetées et envoyées à la base de données.

Après avoir examiné la situation dans laquelle une grande quantité de données expire en même temps, examinons la situation d'échec de l'instance de cache Redis.

Avalanche de cache causée par un échec de l'instance de cache Redis

Dans ce cas, Redis ne peut pas traiter la demande de lecture et la demande sera naturellement envoyée à la base de données.

De manière générale, nous avons deux manières de gérer cette situation :

Faire entretenir le disjoncteur/demander une limitation de courant dans le système d'entreprise.
Précaution à l'avance : créez un cluster Redis à haute fiabilité, comme la commutation de cluster maître-esclave.

Disjoncteur de service, c'est-à-dire qu'en cas de panne de Redis, les demandes d'accès au système de cache sont suspendues. Attendez que Redis revienne à la normale avant d'ouvrir la demande d'accès.

De cette façon, nous devons surveiller l'état d'exécution de Redis ou de la base de données, comme la pression de charge de MySQL, l'utilisation du processeur de Redis, l'utilisation de la mémoire et le QPS, etc. Lorsqu'il est découvert que le cache de l'instance Redis s'est effondré, le service sera suspendu.

Cette situation peut effectivement générer un grand nombre de requêtes et mettre la pression sur la base de données. Cependant, les demandes d'accès seront suspendues, ce qui aura un impact important sur le côté commercial.

Par conséquent, afin de réduire l'impact sur le côté commercial, nous pouvons utiliser la limitation du courant de requête pour contrôler le QPS et éviter trop de requêtes à la base de données. Par exemple, dans l'illustration ci-dessous, il y a 20 000 requêtes par seconde, mais elles ont été interrompues en raison d'une panne de Redis. Notre opération de limitation actuelle a réduit le nombre de qps à 2 000 par seconde, et la base de données n'a toujours eu aucun problème à traiter 2 000 qps.

Panne du cache

La panne du cache signifie que les données de points d'accès individuelles fréquemment consultées ne peuvent pas être mises en cache, puis les demandes sont versées dans la base de données. Cela arrive souvent lorsque les données du hotspot expirent.

Concernant le problème de panne de cache, nous savons qu'il s'agit de données chaudes auxquelles on accède très fréquemment, donc la méthode de traitement est simple et grossière, et le délai d'expiration n'est pas défini directement. Attendez simplement que les données du hotspot ne soient pas consultées fréquemment, puis gérez-les manuellement.

Pénétration du cache

L'avalanche de cache est quelque chose de spécial, cela signifie que les données auxquelles on accède ne se trouvent ni dans le cache Redis ni dans la base de données. Lorsqu'un grand nombre de requêtes entrent dans le système, Redis et la base de données seront soumis à une pression énorme.

Il y a généralement deux raisons à la pénétration du cache :

Les données sont accidentellement supprimées, ce qui entraîne l'absence de données dans le cache et la base de données. Cependant, le client ne le sait pas et continue de demander frénétiquement.
Il existe des cas d'attaques malveillantes : c'est-à-dire que quelqu'un vous cible pour rechercher des données qui ne sont pas disponibles.

Pour la pénétration du cache, vous pouvez vous référer aux solutions suivantes :

consiste à définir une valeur nulle ou une valeur par défaut pour le cache. Par exemple, en cas de pénétration du cache, définissez une valeur nulle/valeur par défaut dans le cache Redis. Les requêtes ultérieures pour cette valeur renverront directement cette valeur par défaut.
Utilisez le filtre Bloom pour déterminer si les données existent et éviter les requêtes à partir de la base de données.
Effectuez la détection des demandes sur le front-end. Par exemple, filtrez certaines requêtes illégales directement sur le front-end au lieu de les envoyer au back-end pour traitement.

Les premier et troisième points sont plus faciles à comprendre et ne seront pas décrits ici. Concentrons-nous sur le deuxième point : les filtres Bloom.

Filtre Bloom

Le filtre Bloom est principalement utilisé pour déterminer si un élément est dans un ensemble. Il se compose d'un vecteur binaire de taille fixe (peut être compris comme un tableau de bits avec une valeur par défaut de 0) et d'une série de fonctions de mappage.

Voyons d'abord comment le filtre Bloom marque une donnée comme une :

Dans la première étape, plusieurs fonctions de mappage (fonctions de hachage) seront utilisées, chaque fonction calculera le hachage des données comme une valeur
; La deuxième étape, ces valeurs de hachage calculées seront respectivement modulo la longueur du tableau de bits, de manière à obtenir la position de chaque valeur de hachage sur le tableau
La troisième étape, la deuxième étape obtiendra Les positions sont définies ; à 1 sur le tableau de bits respectivement.

Avec ces 3 étapes, l'étiquetage des données est terminé. Ensuite, pour interroger les données lorsqu'elles ne sont pas là, procédez comme suit :

Calculez d'abord les multiples positions de ces données dans le tableau de bits
Vérifiez ensuite les valeurs de bits de ces positions dans le tableau de bits respectivement. Seulement si la valeur binaire de chaque position est 1, cela signifie que les données peuvent exister, sinon les données ne doivent pas exister.

En regardant l'image ci-dessous, le principe de base est le suivant.

Comprendre lavalanche de cache Redis, la panne du cache et la pénétration du cache dans un seul article