Comment résoudre les problèmes courants de mise en cache des données basés sur Redis

1. Pénétration du cache

1.1 Description du problème

La pénétration du cache consiste à demander une clé inexistante côté client/navigateur. Cette clé n'existe pas dans Redis, et il n'y a pas de source de données dans la base de données à chaque fois. la demande de cette clé ne peut pas être obtenue depuis le cache, la source de données sera demandée.

Si vous utilisez un identifiant utilisateur inexistant pour accéder aux informations utilisateur, il n'existe pas dans Redis ou dans la base de données. Plusieurs requêtes peuvent submerger la source de données

Solution 1.2

Il ne doit y avoir aucun cache ni requête. Étant donné que le cache est écrit passivement en cas d'échec, le cache n'existe pas. Pour des raisons de tolérance aux pannes, les données qui ne peuvent pas être interrogées ne seront pas mises en cache dans Redis. Cela entraînera la demande de la base de données à chaque fois que les données le seront. not exist est demandé, perdant le sens de la mise en cache.

(1) Si les données renvoyées par une requête sont vides (que les données n'existent pas ou non), nous mettrons toujours en cache le résultat vide (null) et définirons le délai d'expiration du résultat vide pour qu'il soit très court, non plus de cinq minutes au maximum.

(2) Définir une liste accessible (liste blanche) : Utilisez le type bitmaps pour définir une liste accessible. L'identifiant de la liste est utilisé comme décalage des bitmaps. dans le bitmap. Si l’identifiant d’accès n’est pas dans les bitmaps Inside, interceptez et interdisez l’accès.

(3) Utilisez le filtre Bloom

(4) pour la surveillance des données en temps réel. Il s'avère que lorsque le taux de réussite de Redis diminue rapidement, les objets d'accès et les données d'accès sont vérifiés et une liste noire est établie.

2. Panne du cache

2.1 Description du problème

Lorsque l'utilisateur demande des données pour une clé existante, les données de la clé dans Redis sont obsolètes. Si un grand nombre de requêtes simultanées constatent que le cache a expiré, la source de données. sera demandé. Chargez les données et mettez-les en cache dans Redis. À ce stade, une grande quantité de concurrence peut submerger le service de base de données.

2.2 Solution

Lorsque les données d'une certaine clé sont demandées en grand nombre, cette clé est une donnée chaude et doit être prise en compte pour éviter le problème de « panne ».

(1) Données populaires prédéfinies : avant le pic d'accès à Redis, stockez à l'avance certaines données populaires dans Redis et augmentez la longueur de ces clés de données populaires

(2) Ajustement en temps réel : surveillance sur site les données sont populaires, en temps réel Ajustez la durée d'expiration de la clé

(3) Utiliser le verrouillage :

• c'est lorsque le cache expire (la valeur retirée est jugée vide), au lieu de charger la base de données immédiatement.

• Utilisez d'abord certaines opérations de l'outil de mise en cache avec une valeur de retour d'opération réussie (telle que SETNX de Redis) pour définir une clé mutex

• Lorsque l'opération revient avec succès, effectuez l'opération de chargement de base de données et réinitialisez le cache, et enfin supprimez la clé mutex ;

• Lorsque l'opération renvoie un échec, cela prouve qu'il y a un thread chargeant la base de données. Le thread actuel dort pendant un certain temps, puis réessaye l'intégralité de la méthode get cache.

3. Avalanche de cache

3.1 Description du problème

Les données correspondantes existent, mais les données de la clé ont expiré (le cache Redis a expiré et cette clé sera automatiquement supprimée à ce moment-là). Un certain nombre de demandes simultanées accèdent à différentes clés, c'est-à-dire qu'un grand nombre de clés différentes sont accédées en même temps. À ce moment-là, la clé est en phase d'expiration et la base de données sera demandée. submerger le serveur de base de données. Cette situation est appelée avalanche de cache, et la différence avec la panne de cache est que la première est une clé.

Solution 3.2

L'effet d'avalanche lorsque le cache expire a un impact terrible sur le système sous-jacent !

(1) Construire une architecture de cache multi-niveaux :

• cache nginx + cache redis + autres caches (ehcache, etc.)

(2) Utiliser des verrous ou des files d'attente :

• Utilisez le verrouillage Ou utilisez une file d'attente pour garantir qu'il n'y aura pas un grand nombre de threads lisant et écrivant la base de données en même temps, évitant ainsi qu'un grand nombre de requêtes simultanées ne tombent sur le système de stockage sous-jacent en cas de panne. Non applicable aux situations de forte concurrence

(3) Définissez l'indicateur d'expiration pour mettre à jour le cache :

• Enregistrez si les données mises en cache ont expiré (définissez le montant de l'avance). Si elles expirent, cela déclenchera un message. notification à un autre thread pour mettre à jour la clé réelle dans le cache en arrière-plan.

(4) Répartir le délai d'expiration du cache :

• Par exemple, nous pouvons ajouter une valeur aléatoire au délai d'expiration d'origine, par exemple 1 à 5 minutes de manière aléatoire, afin que le délai d'expiration de chaque cache est Le taux de redoublement sera réduit, ce qui rendra difficile la cause d'un échec collectif.

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!