L'avalanche de cache signifie qu'un grand nombre de caches dans Redis échouent tous en même temps. Si un grand nombre de requêtes sont lancées en même temps pendant cette période, la requête accédera directement à la base de données, qui peut surcharger la base de données.
L'avalanche de cache décrit généralement les données qui ne sont pas dans le cache mais dans la base de données, et la requête est envoyée directement à la base de données en raison de l'expiration du délai.
Il existe de nombreuses façons de résoudre l'avalanche de cache :
1. Verrouillez pour garantir un accès monothread au cache. De cette façon, peu de requêtes accèderont à la base de données en même temps.
2. Ne réglez pas le délai d'expiration pour qu'il soit le même. Un exemple typique est celui de l'initialisation des données de préchauffage. Lors du stockage des données dans le cache, une durée aléatoire peut être utilisée pour garantir qu'un grand nombre de caches n'expirent pas en même temps.
3. Si la mémoire le permet, le cache peut être configuré pour ne jamais expirer.
La panne de cache est très similaire à l'avalanche de cache. La différence est que la panne de cache fait généralement référence à une seule panne de cache, et en même temps, de grandes requêtes simultanées doivent accéder à cette clé, provoquant ainsi pression de la base de données.
La méthode de résolution des pannes de cache est très similaire à la méthode de résolution des avalanches de cache :
1. Verrouillez pour garantir un accès monothread au cache. De cette façon, le cache sera réécrit une fois que la première requête aura atteint la base de données, et les requêtes suivantes pourront lire le cache directement.
2. Si la mémoire le permet, le cache peut être configuré pour ne jamais expirer.
La différence essentielle entre la pénétration du cache et les deux phénomènes ci-dessus est que les données accessibles à ce moment n'existent pas dans la base de données, donc puisque la base de données n'existe pas, elle n'existera certainement pas dans le cache , donc si la concurrence est trop importante, les données arriveront continuellement dans la base de données, ce qui exercera une forte pression sur la base de données.
Pour le problème de pénétration du cache, le verrouillage n'a pas un bon effet car la clé elle-même n'existe pas, donc même si le nombre d'accès aux threads est contrôlé, les requêtes arriveront toujours à la base de données en continu.
Pour résoudre le problème de pénétration du cache, les solutions suivantes peuvent généralement être utilisées ensemble :
1. La couche d'interface effectue une vérification et renvoie directement les clés illégales si elles sont trouvées. Par exemple, si la base de données utilise des identifiants à incrémentation automatique, alors si un identifiant non entier ou un identifiant négatif arrive, il peut être renvoyé directement. Ou si un uuid de 32 bits est utilisé, alors si la longueur de l'identifiant n'est pas égale à 32. bits, il peut être renvoyé directement.
2. Mettre en cache les données qui n'existent pas Vous pouvez directement mettre en cache une valeur vide ou autre valeur invalide convenue. Avec cette solution, il est préférable de fixer un délai d'expiration court pour la clé, sinon un grand nombre de clés inexistantes seront stockées dans Redis, ce qui occupera également beaucoup de mémoire.
Concernant la solution de pénétration du cache ci-dessus, réfléchissons-y : si une clé peut contourner la vérification de la première méthode, et qu'il y a un grand nombre de clés inexistantes à ce moment-là accessibles (telles que 100 millions ou 1 milliard), alors tous sont stockés dans le cache à ce moment-là, ce qui occupera un très grand espace et gaspillera beaucoup de mémoire du serveur, ce qui entraînera une mémoire insuffisante.
Alors, existe-t-il une meilleure solution ? C'est le filtre Bloom que nous présenterons ensuite. Le filtre Bloom peut résoudre au maximum le problème du trop grand nombre de valeurs clés.
Peut-être que la plupart des gens savent qu'il existe une telle question d'entretien : comment déterminer rapidement si un élément existe dans 1 milliard de données massivement désordonnées ?
Pour résoudre ce problème, vous devez utiliser un filtre Bloom, sinon la mémoire de la plupart des serveurs ne peut pas stocker une si grande quantité de données.
Le filtre Bloom a été proposé par Bloom en 1970. Il s'agit en fait d'un long vecteur binaire (bitmap) et d'une série de fonctions de mappage aléatoire (fonctions de hachage).
Les filtres Bloom peuvent être utilisés pour savoir si un élément fait partie d'un ensemble. Son avantage est que l'efficacité spatiale et le temps de requête sont bien meilleurs que les algorithmes ordinaires. Son inconvénient est qu'il a un certain taux de mauvaise reconnaissance et est difficile à supprimer.
L'une des structures de données dans Redis est le bitmap. L'implémentation importante du filtre Bloom est l'implémentation du bitmap, qui est un tableau de bits, et chaque position dans ce tableau n'a que 0 et 1. Il y en a deux. États, chaque position n'occupe qu'1 octet, où 0 signifie qu'aucun élément n'existe et 1 signifie qu'il y a un élément. Comme le montre la figure ci-dessous, il s'agit d'un simple exemple de filtre Bloom (une valeur clé peut être déterminée par hachage et opérations de bits là où elle doit tomber) :
Nous avons constaté ci-dessus que le solitaire et le loup tombent dans la même position. Ce phénomène de différentes valeurs clés obtenant la même valeur après le hachage est appelé une collision de hachage. Après qu'une collision de hachage se produise et que des opérations sur les bits soient effectuées, elle se retrouvera certainement dans la même position.
Si trop de collisions de hachage se produisent, cela affectera la précision du jugement. Par conséquent, afin de réduire les collisions de hachage, nous considérons généralement les deux facteurs suivants :
1. Plus le tableau bitmap est grand, plus la mémoire occupée est grande).
2. Augmentez le nombre de fonctions de hachage (la même valeur clé est égale après une fonction, alors la probabilité d'obtenir des résultats égaux après le calcul de deux fonctions de hachage ou plus diminuera naturellement) .
Nous devons considérer les deux méthodes ci-dessus de manière globale : par exemple, augmenter le tableau de bits consommera plus d'espace, et davantage de calculs de hachage consommeront également le CPU et affecteront le temps de calcul final, donc le tableau de bits Quelle est sa taille , combien de fois la fonction de hachage doit être calculée et combien de fois sont appropriés nécessitent une analyse spécifique de la situation spécifique.
Ce qui suit est un filtre Bloom obtenu en passant deux fois la fonction de hachage. D'après la figure ci-dessous, nous pouvons facilement voir que si notre Redis n'existe pas du tout, mais Redis passe les deux. les positions obtenues après deux fonctions de hachage sont déjà 1 (l'une est obtenue par wolf via f2 et l'autre est obtenue par Nosql via f1).
Ainsi, à travers le phénomène ci-dessus, nous pouvons conclure du point de vue du filtre Bloom que le filtre Bloom a principalement deux caractéristiques majeures :
1 Si le filtre Bloom détermine qu'un élément existe, alors cet élément peut être. présent.
2. Si le filtre Bloom détermine qu'un élément n'existe pas, alors cet élément ne doit pas exister.
Du point de vue des éléments, on peut également tirer deux caractéristiques majeures :
1 Si l'élément existe réellement, alors le filtre Bloom déterminera définitivement qu'il existe.
2. Si l'élément n'existe pas, le filtre Bloom peut déterminer qu'il existe.
PS : Il est à noter que si la fonction de hachage est passée N fois, les N positions doivent être 1 pour déterminer son existence. Tant que l'une est 0, on peut déterminer que l'élément n'existe pas. Filtre Bloom au milieu.
Parce qu'il y a toujours un taux de faux positifs dans le filtre Bloom, car les collisions de hachage ne peuvent pas être évitées à 100 %. Le filtre Bloom appelle cette probabilité de faux positifs, à savoir : Probabilité de faux positifs, ou fpp en abrégé.
Lorsque vous utilisez les filtres Bloom dans la pratique, vous pouvez définir vous-même un fpp, puis calculer le nombre de fonctions de hachage et la taille de l'espace de tableau en bits nécessaires en fonction de la théorie des filtres Bloom. Il convient de noter que ce fpp ne peut pas être défini à 100 %, car il n'y a aucune garantie à 100 % que des collisions de hachage ne se produiront pas.
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!
![[Web front-end] Démarrage rapide de Node.js](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
