Comment résoudre le problème de double écriture entre Redis et MySQL

Écrit devant

À proprement parler, il est impossible de garantir la cohérence d'une opération non atomique, à moins que le blocage des lectures et des écritures ne soit utilisé pour obtenir une forte cohérence, l'objectif que nous poursuivons dans l'architecture du cache est donc une cohérence éventuelle.
La mise en cache améliore les performances en sacrifiant une forte cohérence.

Ceci est déterminé par la théorie CAP. Le scénario applicable pour le système de cache est le scénario de cohérence non forte, qui appartient à l'AP dans CAP.

Les trois stratégies de lecture et d'écriture du cache suivantes ont chacune leurs propres avantages et inconvénients, et il n'y en a pas de meilleure.

Trois stratégies de cache en lecture-écriture

Cache-Aside Pattern (mode de contournement du cache)

Cache-Aside Pattern, le mode de contournement du cache, est proposé pour résoudre autant que possible le problème d'incohérence des données entre le cache et la base de données.

Lire : Lisez les données du cache et revenez directement après la lecture. S'il ne peut pas être lu, chargez-le depuis la base de données, écrivez-le dans le cache, puis renvoyez la réponse.
Écrire : Lors de la mise à jour, mettez d'abord à jour la base de données, puis supprimez le cache.

Lecture/écriture (pénétration en lecture-écriture)

Modèle de lecture/écriture Côté serveur, le cache est considéré comme le stockage de données principal, lisant les données et y écrivant des données. La responsabilité du service Cache est de lire et d'écrire les données de la base de données, réduisant ainsi la charge sur l'application.

Parce que le cache distribué que nous utilisons souvent, Redis, ne fournit pas la fonction de cache d'écriture de données dans la base de données, il n'est donc pas beaucoup utilisé.

Ecrire : Vérifiez d'abord le cache, s'il n'existe pas dans le cache, mettez à jour directement la base de données. S'il existe dans le cache, le cache sera d'abord mis à jour, puis le service de cache mettra à jour la base de données par lui-même (Mettre à jour le cache et la base de données simultanément).

Lecture : lit les données du cache et les renvoie directement après la lecture. S'il ne peut pas être lu, chargez-le d'abord depuis la base de données, écrivez-le dans le cache, puis renvoyez la réponse.

Write Behind Pattern (Asynchronous Cache Write)

Write Behind Pattern est très similaire au modèle Read/Write Through. Les deux sont utilisés par le service de cache pour lire et écrire le cache et la base de données.

Cependant, il existe de grandes différences entre les deux : Read/Write Through met à jour le cache et la base de données de manière synchrone, tandis que Write Behind Caching met uniquement à jour le cache et ne met pas directement à jour la base de données. Au lieu de cela, il se met à jour de manière asynchrone. D.B.

Évidemment, cette méthode pose de plus grands défis en matière de cohérence des données. Par exemple, si les données du cache ne peuvent pas être mises à jour de manière asynchrone dans la base de données, le service de cache peut se bloquer, ce qui entraînera un plus grand désastre.

Cette stratégie est également très rare dans notre processus de développement quotidien, mais cela ne signifie pas qu'elle comporte peu de scénarios d'application. Par exemple, l'écriture asynchrone des messages dans la file d'attente des messages sur le disque et le mécanisme InnoDB Buffer Pool de MySQL utilisent tous cette stratégie.

Les performances d'écriture de la base de données sous Write Behind Pattern sont très élevées, ce qui est très approprié pour certains scénarios dans lesquels les données changent fréquemment et les exigences de cohérence des données ne sont pas si élevées, comme le nombre de vues et le nombre de likes.

Analyse du mode de contournement du cache

Quelques questions sur le modèle Cache Aside

Le mode de contournement du cache est ce que nous utilisons le plus dans la vie quotidienne. Sur la base du mode de contournement du cache présenté ci-dessus, nous pouvons nous poser les questions suivantes.

Pourquoi l'opération d'écriture supprime-t-elle le cache au lieu de mettre à jour le cache ?

Réponse : Le fil de discussion A lance d'abord une opération d'écriture et la première étape consiste à mettre à jour la base de données. Le thread B lance une autre opération d'écriture et met à jour la base de données dans la deuxième étape. Pour des raisons de réseau et pour d'autres raisons, le thread B met d'abord à jour le cache et le thread A met à jour le cache.

À ce moment, le cache enregistre les données de A (anciennes données) et la base de données enregistre les données de B (nouvelles données). Les données sont incohérentes et des données sales apparaissent. Si supprimez le cache au lieu de mettre à jour le cache, ce problème de données sales ne se produira pas.

En fait, il est possible de mettre à jour le cache lorsque des opérations d'écriture sont requises, mais nous devons ajouter un verrou/verrou distribué pour garantir qu'il n'y a pas de problèmes de sécurité des threads lors de la mise à jour du cache.

Dans le processus d'écriture des données, pourquoi devons-nous d'abord mettre à jour la base de données, puis supprimer le cache

Réponse : Par exemple, si la requête 1 est une opération d'écriture, si le cache A est d'abord supprimé, et la requête 2 est une opération de lecture, le cache A est lu en premier. On constate que le cache a été supprimé (supprimé par la requête 1), puis lit la base de données, mais à ce moment la requête 1 n'a pas eu le temps de mettre à jour les données dans. temps, donc la requête 2 lit les anciennes données, et la requête 2 lira également les anciennes données. Les données sont placées dans le cache, provoquant une incohérence des données.

En fait, vous pouvez d'abord supprimer le cache, puis mettre à jour la base de données. Par exemple, vous pouvez utiliser la stratégie de double suppression différée
pour dormir pendant 1 seconde, puis éliminer à nouveau le cache. les données provoquées dans un délai d'une seconde peuvent être à nouveau supprimées. Il n'est pas nécessaire que cela dure 1 seconde, cela dépend de votre entreprise, Mais cette approche n'est pas recommandée, car de nombreux facteurs peuvent se produire dans cette seconde, et l'incertitude est trop grande.

Dans le processus d'écriture des données, est-il possible de mettre à jour d'abord la base de données, puis de supprimer le cache ?

Réponse : En théorie, une incohérence des données peut toujours se produire, mais la probabilité est très faible.

Supposons qu'il y aura deux requêtes, une demandant à A d'effectuer une opération de requête et une demandant à B d'effectuer une opération de mise à jour, alors la situation suivante se produira

(1) Le cache vient d'expirer
(2) Demande à A d'interroger la base de données et d'obtenir une ancienne valeur
(3) Demande à B d'écrire la nouvelle valeur dans la base de données
(4) Demande à B de supprimer le cache
(5 ) Demande A pour trouver l'ancienne valeur est écrite dans le cache ok Si la situation ci-dessus se produit, des données sales se produiront effectivement.

Cependant, la probabilité que cela se produise n'est pas élevée

Il existe une condition congénitale pour que la situation ci-dessus se produise, c'est-à-dire que l'opération d'écriture de la base de données à l'étape (3) prend moins de temps que l'opération de lecture de la base de données à l'étape (2) Il est possible que l'étape (4) précède l'étape (5).

Cependant, si vous y réfléchissez bien, l'opération de lecture de la base de données est beaucoup plus rapide que l'opération d'écriture (sinon, pourquoi séparons-nous la lecture et l'écriture ? Le sens de séparer la lecture et l'écriture est que l'opération de lecture est plus rapide et consomme moins de ressources), donc les étapes ( 3) Cela prend moins de temps que l'étape (2). Cette situation se produit rarement.

Y a-t-il d'autres raisons à l'incohérence ?

Réponse : Si la suppression du cache échoue, cela provoquera un problème d'incohérence

Comment le résoudre ?
Utilisez Canal pour vous abonner au binlog de la base de données et obtenir les données à exploiter. Démarrez un autre programme pour obtenir les informations de ce programme d'abonnement et supprimez le cache.

Défauts du modèle de cache mis à part

Défaut 1 : les premières données demandées ne doivent pas être dans le cache

Solution : les données du point d'accès peuvent être mises dans le cache à l'avance.

Défaut 2 : les opérations d'écriture fréquentes entraîneront la suppression fréquente des données dans le cache, ce qui affectera le taux de réussite du cache.

Scénario de forte cohérence entre les données de la base de données et du cache : lors de la mise à jour de la base de données, le cache est également mis à jour, mais nous devons ajouter un verrou/verrou distribué pour garantir qu'il n'y a pas de problèmes de sécurité des threads lors de la mise à jour du cache. Les scénarios dans lesquels les données de la base de données et du cache sont incohérentes peuvent être temporairement autorisés : lors de la mise à jour de la base de données, le cache est également mis à jour, mais un délai d'expiration relativement court est ajouté au cache. Cela garantit que même si les données sont incohérentes, l'impact. sera relativement faible.

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!