Analysons ensemble les problèmes de cohérence du cache Redis, de pénétration du cache, de panne de cache et d'avalanche de cache

Cet article vous apporte des connaissances pertinentes sur Redis, qui présente principalement les problèmes liés à la cohérence du cache, à la pénétration du cache, à la panne du cache, à l'avalanche de cache et à la synchronisation d'écriture des données mises en cache et à la cohérence de la base de données. Jetons-y un coup d'œil ensemble, je l'espère. sera utile à tout le monde.

Recommandations associées : "Analyse des problèmes de stockage des touches de raccourci dans Redis et discussion sur les solutions aux exceptions de cache"

(1) Problème de cohérence d'invalidation du cache

L'utilisation générale du cache est : Lire le cachez d'abord, s'il n'existe pas, lisez-le à partir de la base de données et écrivez le résultat dans le cache ; la prochaine fois que les données seront lues, les données pourront être obtenues directement à partir du cache. [Recommandation associée : Tutoriel vidéo Redis]

La modification des données consiste à invalider directement les données mises en cache, puis à modifier le contenu de la base de données pour éviter une modification réussie de la base de données, mais les données mises en cache ne sont pas nettoyées en raison de problèmes de réseau ou autres, ce qui entraîne données sales. Mais cela ne peut toujours pas éviter la génération de données sales. Dans un scénario simultané : supposons que l'entreprise ait un grand nombre de demandes de lecture et de modification pour les données Key:Hello Value:World. Le thread A lit Key:Hello from OCS, obtient le résultat Not Found, commence à demander des données à la base de données et obtient ensuite les données Key:Hello Value:World ; il se prépare ensuite à écrire ces données sur OCS, mais avant d'écrire sur OCS (réseau). , Attendre le CPU peut entraîner un ralentissement de la vitesse de traitement du thread A.) Un autre thread B demande de modifier les données Key:Hello Value:OCS et exécute d'abord l'action de cache d'invalidation (car le thread B ne sait pas si ces données existent , il effectue donc directement l'opération d'invalidation). OCS a traité avec succès la requête invalide. Revenez au thread A pour continuer à écrire OCS et écrivez Key:Hello Value:World dans le cache. La tâche du thread A se termine également avec succès par la modification du contenu des données de la base de données en Key:Hello Value:OCS. Afin de résoudre ce problème, OCS a étendu le protocole Memcached (le cloud public le supportera bientôt) et ajouté l'interface deleteAndIncVersion. Cette interface ne supprime pas réellement les données, mais étiquette les données pour indiquer qu'elles ont expiré et augmente le numéro de version des données. Si les données n'existent pas, NULL est écrit et un numéro de version aléatoire des données est également généré. L'écriture OCS prend en charge la comparaison atomique des numéros de version : en supposant que le numéro de version entrant est cohérent avec le numéro de version des données enregistré par OCS ou que les données d'origine n'existent pas, l'écriture est autorisée, sinon la modification est refusée.

Retour à la scène tout à l'heure : le fil de discussion A lit Key:Hello from OCS, obtient le résultat Not Found, commence à demander des données à la base de données et obtient les données Key:Hello Value:World, puis se prépare à écrire ces données dans OCS, Les informations sur le numéro de version sont par défaut 1 ; avant que A n'écrive dans OCS, un autre thread B lance une action pour modifier les données Key:Hello Value:OCS. Il exécute d'abord l'action de suppression du cache, OCS gère avec succès la requête deleteAndIncVersion et génère une version aléatoire. nombre de 12345 (convention supérieure à 1000). Revenez au thread A et continuez à écrire sur OCS, en demandant d'écrire Key:Hello Value:World. À ce stade, le système de cache constate que les informations sur le numéro de version entrant ne correspondent pas (1 ! = 12345), l'écriture échoue et le. La tâche du thread A se termine. Le thread B a également modifié avec succès le contenu des données de la base de données en Key:Hello Value:OCS.

À l'heure actuelle, les données dans OCS sont Key:Hello Value:NULL Version:12345 ; les données dans DB sont Key:Hello Value:OCS. Dans les tâches de lecture suivantes, les données dans DB seront réessayées d'écrire dans OCS. .

(2) Le problème de la synchronisation d'écriture des données mises en cache et de la cohérence de la base de données

À mesure que l'échelle du site Web augmente et que la fiabilité s'améliore, il sera confronté au déploiement de plusieurs IDC. Chaque IDC dispose d'une base de données et d'un système de cache indépendants. cette fois, la cohérence du cache est devenue un problème majeur.

Tout d'abord, afin de garantir une efficacité élevée, le système de cache empêchera les E/S sur le disque, même lors de l'écriture de BINLOG. Bien sûr, pour des raisons de performances, le système de cache ne peut supprimer que de manière synchrone et non écrire de manière synchrone, donc le cache la synchronisation aura généralement priorité sur l'arrivée de la synchronisation de la base de données (après tout, le système de cache L'efficacité est beaucoup plus élevée), alors il y aura un scénario où il n'y aura pas de données dans le cache et d'anciennes données dans la base de données. À ce stade, il y a une demande commerciale de données et le cache de lecture est introuvable. Les anciennes données lues à partir de la base de données et chargées dans le cache sont toujours des données anciennes. Lorsque la synchronisation des données de la base de données arrive, seule la base de données est mise à jour. et les données sales mises en cache ne peuvent pas être effacées.

Comme le montre la situation ci-dessus, la cause première de l'incohérence est que les systèmes hétérogènes ne peuvent pas se synchroniser de manière collaborative. Ils ne peuvent pas garantir que les données de la base de données soient synchronisées en premier et que les données mises en cache soient synchronisées ultérieurement. Nous devons donc considérer comment le système de cache attend la synchronisation de la base de données, ou les deux peuvent-ils partager un mécanisme de synchronisation ? La synchronisation du cache s'appuie également sur DB BINLOG qui est une solution réalisable.

La base de données dans IDC1 est synchronisée avec la base de données dans IDC2 via BINLOG. Dans ce cas, la modification des données IDC2-DB générera également son propre BINLOG. La synchronisation des données mises en cache peut être effectuée via IDC2-DB BINLOG. Une fois que le module de synchronisation du cache a analysé le BINLOG, il invalide la clé de cache correspondante et modifie la synchronisation de parallèle à série, garantissant ainsi l'ordre.

(3) Pénétration du cache (la base de données a subi un trafic de requêtes inutile)

Méthode 1 : C'est un filtre Bloom. Il s'agit d'un algorithme probabiliste et d'une structure de données extrêmement économes en espace, utilisés pour déterminer si un élément fait partie d'un ensemble (similaire à Hashset). Son noyau est un long vecteur binaire et une série de fonctions de hachage. Implémentez le filtre Bloom à l'aide de la goyave de Google. 1) Il existe un taux d'erreurs de calcul à mesure que le nombre d'éléments stockés augmente, le taux d'erreurs de calcul augmente également. 2) Dans des circonstances normales, les éléments ne peuvent pas être supprimés du filtre Bloom. 3) Le processus de détermination de la longueur du tableau et du nombre d'éléments. Les fonctions de hachage sont complexes et la distribution. Quels sont les scénarios d'utilisation du filtre Long ? 1) Filtrage des adresses spam (le nombre d'adresses est énorme) 2) Déduplication des adresses URL du robot 3) Résoudre le problème de panne de cache

Méthode 2 : stocker les résultats vides et définir l'heure des résultats vides

(4) Avalanche de cache ( Définir le cache sur le même délai d'expiration provoquera une inondation de base de données)

Méthode 1 : La plupart des concepteurs de systèmes envisagent d'utiliser des verrous ou des files d'attente pour garantir les écritures monothread (processus) dans le cache, évitant ainsi la chute d'un grand nombre de requêtes simultanées. lors d'une panne Sur le système de stockage sous-jacent

Méthode 2 : Délai d'expiration aléatoire

(5) Panne du cache (touche de raccourci, petite avalanche provoquée par un grand nombre de requêtes de lecture simultanées)

Lorsque le cache expire à un certain moment À ce stade, il y a un grand nombre de demandes simultanées pour cette clé. Lorsque ces demandes constatent que le cache a expiré, elles chargent généralement les données de la base de données backend et les réinitialisent dans le cache. À l'heure actuelle, des requêtes simultanées volumineuses peuvent instantanément submerger la base de données backend

Méthode 1 : 1. Utilisez la clé mutex (clé mutex) prise en charge par le cache de distribution pour définir une clé mutex. Lorsque l'opération est renvoyée avec succès, effectuez le chargement de la base de données. opération et réinitialiser le cache, c'est-à-dire qu'il n'y aura qu'un seul traitement de chargement DB Thread.

Méthode 2 : utilisez la clé mutex à l'avance : définissez une valeur de délai d'attente (timeout1) à l'intérieur de la valeur, timeout1 est plus petit que le délai d'expiration réel du cache mémoire (timeout2). Lorsque timeout1 est lu à partir du cache, il s'avère qu'il a expiré. Le moment venu, prolongez immédiatement le délai d'attente1 et réinitialisez-le dans le cache. Ensuite, chargez les données de la base de données et définissez-les dans le cache. Cela augmente l'intrusion du code métier et augmente la complexité du codage. : Du point de vue de Redis, il n'y a en effet pas de délai d'expiration, ce qui garantit qu'il n'y aura pas de problème d'expiration de clé de hotspot, c'est-à-dire qu'elle n'expirera pas "physiquement" d'un point de vue fonctionnel, si elle n'expire pas. , ne devient-il pas statique ? Nous stockons le délai d'expiration dans la valeur correspondant à la clé. S'il s'avère qu'elle est sur le point d'expirer, le cache est construit via un thread asynchrone en arrière-plan, ce qui est une expiration "logique"

doit être analysé en fonction d'une activité spécifique. Habituellement, nous utilisons la stratégie LRU pour gérer le débordement, et les stratégies de persistance RDB et AOF de Redis pour assurer la sécurité des données. dans certaines circonstances

Pour plus de connaissances sur la programmation, veuillez visiter :

!

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!