Comment gérer trois exceptions majeures dans le cache Redis

1. Contexte

Redis est un système de stockage de structure de données clé-valeur entièrement open source, conforme à BSD et hautes performances. Il prend en charge la persistance des données et peut enregistrer les données en mémoire sur le disque. prend non seulement en charge les données de type clé-valeur simples, mais fournit également le stockage de structures de données telles que liste, ensemble, zset, hachage, etc., ce qui est très puissant. Redis prend également en charge la sauvegarde des données, c'est-à-dire les données en mode maître-esclave. . sauvegarde, augmentant ainsi la disponibilité. La vitesse de lecture et d'écriture rapide est la plus critique, car en tant que solution de mise en cache la plus fréquemment utilisée dans notre développement quotidien, elle a été largement utilisée. Cependant, dans le processus de candidature réel, il y aura des situations anormales telles qu'une avalanche de cache, une panne de cache et une pénétration du cache. Si ces situations sont ignorées, cela peut avoir des conséquences catastrophiques. Ce qui suit analyse principalement ces exceptions de cache et les solutions de traitement courantes. .

2. Avalanche de cache

(1) Qu'est-ce que

Un grand nombre de requêtes qui auraient dû être traitées dans le cache Redis sur une période de temps sont envoyées à la base de données pour traitement, provoquant une pression sur la base de données augmenter rapidement, et même dans les cas graves. Cela peut provoquer le crash de la base de données, provoquant le crash de l'ensemble du système, tout comme une avalanche, déclenchant un effet de chaîne, c'est pourquoi on l'appelle une avalanche de cache.

(2) Pourquoi

Les raisons courantes de la situation ci-dessus sont principalement les deux points suivants :

• Une grande quantité de données mises en cache expire en même temps, ce qui entraîne l'expiration des données qui devraient être demandées au cache. à ré-obtenir à partir de la base de données.

• Si Redis lui-même échoue et ne peut pas gérer la demande, alors la demande sera naturellement envoyée à la base de données.

(3) Que faire

Dans le cas où une grande quantité de données mises en cache expire en même temps :

• Lorsque vous définissez réellement le délai d'expiration, vous devez essayer d'éviter le scénario dans lequel un un grand nombre de clés expirent en même temps. Si cela se produit, transmettez-le. Réglez le délai d'expiration de manière aléatoire, ajustez-le et de manière uniforme pour éviter l'expiration en même temps.

• Ajoutez un verrou mutex afin que les opérations de construction du cache ne soient pas effectuées en même temps.

• Stratégie à double clé, la clé primaire est le cache d'origine et la clé de sauvegarde est le cache de copie. Lorsque la clé primaire expire, la clé de sauvegarde est accessible. Le délai d'expiration du cache de la clé primaire est défini sur court. -term, et la clé de sauvegarde est définie sur long terme.

• Stratégie de cache de mise à jour en arrière-plan, utilisant des tâches planifiées ou des files d'attente de messages pour mettre à jour ou supprimer le cache Redis, etc.

Pour la situation où Redis lui-même échoue :

• Au niveau de la prévention, vous pouvez créer un cluster haute disponibilité via des nœuds maître-esclave, c'est-à-dire qu'après le blocage de l'instance maître Redis, il peut y avoir autres bibliothèques esclaves Basculez rapidement vers la base de données principale et continuez à fournir des services.

• Une fois qu'un incident se produit, afin d'éviter que la base de données ne plante en raison d'un trop grand nombre de demandes, un disjoncteur de service ou une stratégie de limitation de courant de demande peut être adoptée. Bien sûr, le disjoncteur de service est relativement grossier, arrêtant le service jusqu'à ce que le service Redis soit rétabli, et la limite de courant de demande est relativement douce, garantissant que certaines demandes peuvent être traitées. Il ne s'agit pas d'une approche universelle. , mais encore faut-il choisir une solution appropriée en fonction de la situation spécifique de l'entreprise.

3. Panne du cache

(1) Qu'est-ce que

La panne du cache se produit généralement dans les systèmes à haute concurrence, où un grand nombre d'utilisateurs simultanés demandent simultanément des données qui ne sont pas dans le cache mais dans la base de données , c'est-à-dire qu'en même temps, le cache de lecture n'a pas lu les données, et en même temps il est allé dans la base de données pour récupérer les données, provoquant une augmentation instantanée de la pression sur la base de données. Contrairement à l'avalanche de cache, la panne du cache fait référence à une requête simultanée des mêmes données. Cela signifie que différentes données ont expiré et que de nombreuses données sont introuvables, la base de données est donc recherchée.

(2) Pourquoi

En fait, la raison courante de cette situation est qu'un certain cache de données chaudes a expiré. Puisqu'il s'agit de données chaudes, le nombre de requêtes simultanées est important, donc lorsqu'il expirera, il y en aura toujours. un grand nombre de requêtes arrivent en même temps et on n'a pas le temps de mettre à jour le cache. Tout est envoyé à la base de données.

(3) Que faire

Il existe deux solutions courantes à cette situation :

• Ne définissez simplement pas de délai d'expiration pour les données du hotspot, afin qu'elles n'expirent pas, et bien sûr ce qui précède ne se produira pas. Si tel est le cas, si vous souhaitez le nettoyer plus tard, vous pouvez le faire en arrière-plan.

• Ajoutez un verrou mutex, c'est-à-dire qu'après son expiration, à l'exception de la première demande de requête, la demande de verrouillage peut être obtenue à partir de la base de données et mise à jour dans le cache. Les autres seront bloquées jusqu'à ce que le verrou soit libéré. en même temps, le nouveau cache est également mis à jour et des requêtes ultérieures seront adressées au cache, de sorte qu'une panne du cache ne se produise pas.

4. Pénétration du cache

(1) Qu'est-ce que

La pénétration du cache signifie que les données ne sont ni dans Redis ni dans la base de données, ce qui signifie qu'à chaque fois qu'une requête arrive, elle ne peut pas être trouvée dans le cache. pour obtenir la clé correspondante, je dois accéder à la base de données pour interroger à nouveau à chaque fois, et constater que la base de données ne l'a pas, ce qui équivaut à deux requêtes inutiles. De cette façon, les requêtes peuvent contourner le cache et vérifier directement la base de données. Si quelqu'un souhaite attaquer le système de manière malveillante à ce moment-là, il peut délibérément utiliser des valeurs nulles ou d'autres valeurs inexistantes pour effectuer des requêtes fréquentes, ce qui le fera. exercer une plus grande pression sur la base de données.

(2) Pourquoi

La raison de ce phénomène est en fait facile à comprendre. Si l'utilisateur n'a pas effectué les opérations ou traitements correspondants sur certaines informations dans la logique métier, alors la base de données ou le cache correspondant où les informations sont stockées le sera naturellement. ne soit pas là. Les données correspondantes, il est facile que les problèmes ci-dessus se produisent.

(3) Que faire

Pour la pénétration du cache, il existe généralement trois solutions :

• Les restrictions sur les requêtes illégales font principalement référence à la vérification des paramètres, à la vérification de l'authentification, etc., de sorte que dès le début Bloquer un un grand nombre de demandes illégales est un moyen nécessaire au développement réel des affaires.

• Cache les valeurs vides ou les valeurs par défaut. Si les données qui ne peuvent pas être obtenues à partir du cache ne sont pas obtenues dans la base de données, nous mettrons toujours en cache le résultat vide et définirons un délai d'expiration plus court. La valeur par défaut de ce paramètre est stockée dans le cache, de sorte que la valeur soit obtenue une deuxième fois dans le cache sans continuer à accéder à la base de données, ce qui peut empêcher un grand nombre de requêtes malveillantes d'utiliser de manière répétée la même clé pour attaquer.

• Utilisez le filtre Bloom pour déterminer rapidement si des données existent. Alors, qu'est-ce qu'un filtre Bloom ? Pour faire simple, il peut introduire plusieurs fonctions de hachage indépendantes pour garantir que la détermination du poids des éléments est effectuée dans un espace et un taux d'erreur de jugement donnés. Parce que nous savons qu'il existe une situation telle qu'une collision de hachage, alors si une seule fonction de hachage est utilisée, la probabilité de collision augmentera évidemment. Afin de réduire ce conflit, nous pouvons introduire plusieurs fonctions de hachage supplémentaires et filtrer Bloom Le noyau. L'idée de l'algorithme de hachage est d'utiliser plusieurs fonctions de hachage différentes pour résoudre un tel conflit. Ses avantages sont une efficacité spatiale élevée et un temps de requête court, dépassant de loin les autres algorithmes. Son inconvénient est qu'il y aura un certain taux de mauvaise reconnaissance. Il ne peut pas garantir complètement que la clé demandée passera la vérification du filtre Bloom, après. Quoi qu’il en soit, en théorie, il y aura toujours des conflits, aussi faible soit-elle. Cependant, tant qu'elle ne réussit pas la vérification du filtre Bloom, la clé ne doit pas exister. Tant que celle-ci est utilisée, vous pouvez filtrer la plupart des demandes de clés inexistantes, ce qui est suffisant dans les scénarios normaux.

5. Autres

En plus des trois problèmes courants d'exception de cache Redis ci-dessus, les deux termes préchauffage du cache et rétrogradation du cache sont également souvent entendus. Il ne s'agit pas tant d'un problème d'exception que de deux termes. méthode de traitement d'optimisation.

(1) Préchauffage du cache

Avant et après la mise en ligne du système, le préchauffage du cache chargera les données de cache pertinentes directement dans le système de cache sans dépendre des opérations de l'utilisateur. Cela peut éviter le problème d'interroger d'abord la base de données, puis de mettre en cache les données lorsque l'utilisateur le demande. Les utilisateurs interrogent directement les données mises en cache qui ont été préchauffées à l'avance. Cela peut éviter qu'un trafic hautement simultané accède à la base de données dans les premières étapes du lancement du système, provoquant une pression de trafic sur la base de données.

Selon différentes quantités de données, les méthodes suivantes peuvent être utilisées :

• La quantité de données n'est pas importante : Elle sera chargée automatiquement au démarrage du projet.

• Grande quantité de données : Actualisez régulièrement le cache en arrière-plan.

• Énorme quantité de données : Effectuez uniquement des opérations de préchargement du cache pour les données de hotspot.

(2) Rétrogradation du cache

La rétrogradation du cache signifie que lorsque le cache échoue ou qu'il y a un problème avec le service de cache, afin d'éviter que l'échec du service de cache ne provoque un problème d'avalanche dans la base de données, la base de données n'est pas consulté, mais pour certaines raisons, je veux toujours m'assurer que le service est toujours fondamentalement disponible, même s'il s'agira certainement d'une perte de service. Par conséquent, pour les données mises en cache sans importance, nous pouvons adopter une stratégie de dégradation du service.

Il existe généralement deux méthodes :

• Accéder directement au cache de données dans la partie mémoire.

• Retournez directement à la valeur par défaut des paramètres système.

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!