Quelles sont les causes de l'avalanche de pannes Redis et comment la résoudre

1. Avant-propos

Tout le monde sait que l'un des goulots d'étranglement des ordinateurs est l'E/S. Afin de résoudre le problème de l'inadéquation entre la mémoire et la vitesse du disque, un cache est généré pour mettre certaines données chaudes en mémoire et y accéder à tout moment, ce qui réduit le coût de connexion à l’ordinateur. Lien de demande de base de données pour éviter le blocage de la base de données. Il convient de noter que qu'il s'agisse d'une panne ou de la pénétration et de l'avalanche mentionnées plus loin, tout cela repose sur le principe d'une concurrence élevée, par exemple lorsqu'un certain raccourci clavier dans le cache échoue.

2. Cause du problème

Il y a deux raisons principales :

• 1. La clé a été éliminée par le remplacement de la page ;

• Pour la première raison, dans Redis, la clé a un délai d'expiration. Si la clé expire à un certain moment (si le centre commercial organise un événement, à partir de minuit), alors toutes les demandes de requête pour un certain produit après. minuit sera poussé vers la base de données, provoquant le crash de la base de données.

Pour la deuxième raison, parce que la mémoire est limitée, les nouvelles données doivent être mises en cache à tout moment et les anciennes données doivent être éliminées. Par conséquent, dans une certaine stratégie de remplacement de page (illustration des algorithmes courants de remplacement de page), les données doivent être éliminées. Si certains Si personne ne se soucie du produit avant sa promotion, il sera définitivement éliminé.

3. Idées de traitement pour gérer les pannes

La demande de traitement normale est comme indiqué dans la figure :

Étant donné que l'expiration de la clé est inévitable, lorsqu'un trafic élevé arrive sur Redis, selon les caractéristiques monothread de Redis , on peut considérer que la tâche est en Elle est exécutée séquentiellement dans la file d'attente. Lorsque la requête atteint Redis et qu'il s'avère que la Clé a expiré, une opération est effectuée : la mise en place du verrou.

Ce processus est à peu près le suivant :

La demande arrive à Redis, et il s'avère que la clé Redis a expiré. Vérifiez s'il y a un verrou. S'il n'y a pas de verrou, retournez à l'arrière du. file d'attente et file d'attente

• Définissez le verrou. Notez que cela doit être setnx() et Not set(), car il peut y avoir d'autres threads qui ont défini le verrou. Une fois que vous avez obtenu le verrou, allez-y. à la base de données pour obtenir les données et relâchez le verrou après le retour de la demande.

• Mais cela soulève une nouvelle question. Que se passe-t-il si vous obtenez le verrou et demandez à obtenir les données, puis raccrochez ? C'est-à-dire que le verrou n'est pas libéré et que d'autres processus attendent le verrou. est :
  Oui. Le verrou définit un délai d'expiration. S'il atteint le délai d'expiration et n'est pas libéré, il sera automatiquement libéré. ​​Le problème revient. Il est facile de dire que le verrou est bloqué, mais que se passe-t-il si le verrou est bloqué. expirer ? C'est-à-dire que les données ne sont pas supprimées dans le délai défini, mais le verrouillage. En raison de l'expiration, l'idée courante est que la valeur du délai d'expiration du verrouillage est incrémentée, mais cela n'est pas fiable car la première demande peut expirer si. les requêtes suivantes expirent également, après plusieurs délais d'attente consécutifs, la valeur du délai d'expiration du verrouillage sera inévitablement extrêmement grande. Oui, cela présente trop d'inconvénients.

Une autre idée est de démarrer un autre thread pour la surveillance. Si le thread récupérant les données ne raccroche pas, retardez de manière appropriée le délai d'expiration du verrou.

4. Pénétration

La principale raison de la pénétration est que de nombreuses requêtes accèdent à des données qui n'existent pas dans la base de données. Par exemple, un centre commercial qui vend des livres a été invité à interroger des produits à base de thé, à cause du cache Redis. est principalement utilisé pour mettre en cache les données chaudes, les données qui n'existent pas dans la base de données ne peuvent pas être mises en cache. Ce type de trafic anormal atteindra directement la base de données et renverra des résultats de requête « aucun ».

Pour faire face à ce type de demande, la solution est d'ajouter une couche de filtres à la demande d'accès, tels que le filtre Bloom, le filtre Bloom amélioré et le filtre coucou.

En plus des filtres Bloom, vous pouvez ajouter des vérifications de paramètres. Par exemple, les identifiants de données de base de données sont généralement incrémentés. Si vous demandez des paramètres tels que id = -10, Redis sera inévitablement contourné. vous pouvez vérifier les tests d'authenticité de l'utilisateur et d'autres opérations.

5. Avalanche

L'avalanche est similaire à la panne. La différence est que la panne se produit lorsqu'une clé de point d'accès tombe en panne à un moment donné, tandis qu'une avalanche se produit lorsqu'un grand nombre de clés de point d'accès échouent en un instant. mettant l'accent sur les stratégies pour résoudre les avalanches. Il s'agit d'un délai d'expiration aléatoire, ce qui est très imprécis. Par exemple, lorsqu'une banque exerce des activités, le coefficient d'intérêt était de 2%, mais après zéro, le coefficient est modifié à 3%. Dans ce cas, la clé correspondante de l'utilisateur peut-elle être remplacée par une expiration aléatoire ? Si des données antérieures sont utilisées, on parle de données sales.

Évidemment pas possible, économisez le même argent f0c ; Vous économisez 3 millions d'intérêts jusqu'à la fin de l'année, et le voisin n'en a que 2 millions. Ce n'est pas un combat, je plaisante~

La bonne idée est de. vérifiez d'abord si la clé expire au bon moment. Si le problème est lié au sexe mais non au temps, il peut être résolu par un délai d'expiration aléatoire.

Si cela est lié au temps, par exemple, la banque que nous venons de mentionner modifie un certain coefficient un certain jour, alors une solution de répartition des dépendances solide doit être utilisée en premier.

Lors de la mise à jour de la clé de point d'accès en arrière-plan, la couche métier retardera la demande entrante, par exemple en dormant brièvement pendant quelques millisecondes ou secondes, pour fournissez les clés de point d’accès de mise à jour ultérieures pour répartir la pression.

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!