Comment résoudre l'avalanche causée par Redis

Cause de l'avalanche :

La compréhension simple de l'avalanche de cache est la suivante : en raison de la défaillance du cache d'origine (ou les données ne sont pas chargées dans le cache), le nouveau cache n'est pas arrivé pendant cette période (le cache est normalement obtenu auprès de Redis, comme indiqué ci-dessous) toutes les requêtes qui auraient dû accéder au cache sont interrogées dans la base de données, ce qui exerce une pression énorme sur le processeur et la mémoire de la base de données. Dans certains cas, cela peut entraîner une indisponibilité de la base de données et un effondrement du système.

La solution de base est la suivante :

Premièrement, la plupart des concepteurs de systèmes envisagent d'utiliser des verrous ou des files d'attente pour garantir qu'il n'y aura pas un grand nombre de threads lisant et écrivant dans la base de données en même temps. . Éviter une pression excessive sur la base de données en cas de panne du cache, même si cela peut alléger dans une certaine mesure la pression sur la base de données, cela réduit également le débit du système.

Deuxièmement, analysez le comportement des utilisateurs et essayez de répartir uniformément le temps d'invalidation du cache.

Troisièmement, si un certain serveur de cache est en panne, vous pouvez envisager un serveur principal et une sauvegarde, tels que : redis principal et sauvegarde, mais la double mise en cache implique des transactions de mise à jour, et la mise à jour peut lire des données sales, ce qui doit être résolu. .

Solution à l'effet d'avalanche Redis :

1. Les verrous distribués peuvent être utilisés pour la version autonome, les verrous locaux

2. Méthode middleware de message

3. Cache de niveau un et niveau deux Redis+Ehchache

4. Délai d'expiration des clés Redis uniformément réparti

Explication :

1. Quand tout à coup, il y en a un grand nombre. des requêtes à la base de données Lors de l'utilisation du serveur, des restrictions de requêtes sont mises en œuvre. En utilisant le mécanisme ci-dessus, il est garanti qu'un seul thread (requête) fonctionne. Sinon, faites la queue et attendez (verrouillage distribué du cluster, verrouillage local autonome). Réduisez le débit du serveur et la faible efficacité.

Ajouter pour verrouiller !

Assurez-vous qu'un seul thread peut entrer. En fait, une seule requête peut effectuer l'opération de requête

Vous pouvez également utiliser la stratégie de limitation actuelle ici ~.

2. Utilisez un middleware de messages pour résoudre

Cette solution est la solution la plus fiable !

Le middleware de messages peut résoudre une concurrence élevée ! ! !

S'il n'y a aucune valeur dans Redis lors de l'accès à un grand nombre de requêtes, les résultats de la requête seront stockés dans le middleware de messages (en utilisant la fonctionnalité de synchronisation asynchrone MQ)

3. Créez un cache de deuxième niveau. A1 est le cache d'origine et A2 est le cache de copie. Lorsque A1 échoue, vous pouvez accéder à A2. Le délai d'expiration du cache de A1 est défini sur court terme et A2 est défini. défini sur long terme (ce point est un supplément)

4. Définissez différents délais d'expiration pour différentes clés afin de rendre le temps d'invalidation du cache aussi uniforme que possible.

Pour plus de connaissances sur Redis, veuillez visiter la colonne Tutoriel d'utilisation de Redis !

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!