Dans les systèmes à grande échelle, afin de réduire la pression de la base de données, un mécanisme de mise en cache est généralement introduit. Une fois la mise en cache introduite, il est facile de provoquer des incohérences entre le cache et les données de la base de données, ce qui fait que les utilisateurs voient d'anciennes données.
Afin de réduire l'incohérence des données, le mécanisme de mise à jour du cache et de la base de données est particulièrement important, puis laissez tout le monde entrer dans la fosse.
Cache de côté
Le cache de côté, également connu sous le nom de cache de contournement, est une stratégie de mise en cache couramment utilisée.
(1) Processus commun de demande de lecture
Mettre en cache la demande de lecture
L'application juge d'abord si le cache contient les données, le cache atteint les données directement, le cache manque le cache pénètre dans la base de données, interroge les données de la base de données, puis les réécrit dans le cache, et enfin renvoie les données au client .
(2) Processus commun de demande d'écriture
Cache de la demande d'écriture
Mettez d'abord à jour la base de données, puis supprimez les données du cache.
Après avoir lu l'image de la demande d'écriture, certains élèves devront peut-être se demander: Pourquoi supprimer le cache et mettre à jour directement? Il y a plusieurs fosses impliquées ici, nous les marchons étape par étape.
Cache de côté en marchant sur la fosse
Si vous utilisez la mauvaise stratégie de mise en cache, vous rencontrerez des puits profonds. Marchons-les un par un ci-dessous.
Première étape: mettez d'abord à jour la base de données, puis mettez à jour le cache
S'il y a deux demandes d'écriture qui doivent mettre à jour les données en même temps, chaque demande d'écriture met d'abord à jour la base de données, puis met à jour le cache. Dans un scénario simultané, une incohérence des données peut se produire.
Mettez d'abord à jour la base de données, puis mettez à jour le cache
Le processus d'exécution comme indiqué dans la figure ci-dessus:
(1) Écrire la demande 1 pour mettre à jour la base de données et mettre à jour le champ d'âge à 18;
(2) Écrire la demande 2 pour mettre à jour la base de données et mettre à jour le champ d'âge à 20;
(3) Ecrire la demande 2 pour mettre à jour le cache, et définir l'âge du cache à 20;
(4) Ecrire la demande 1 pour mettre à jour le cache, et définir l'âge du cache à 18;
Après l'exécution, le résultat attendu est que l'âge de la base de données est de 20 ans, celui du cache est de 20 ans et celui du cache de résultat est de 18 ans. Les données mises en cache ne sont donc pas à jour et les données incorrectes apparaissent.
Étape 2: supprimez d'abord le cache, puis mettez à jour la base de données
Si le flux de traitement d'une demande d'écriture consiste à supprimer d'abord le cache puis à mettre à jour la base de données, il peut y avoir des incohérences de données dans un scénario simultané d'une demande de lecture et d'une demande d'écriture.
Supprimez d'abord le cache, puis mettez à jour la base de données
Le processus d'exécution comme indiqué dans la figure ci-dessus:
(1) demande d'écriture pour supprimer les données mises en cache;
(2) demande de lecture Hit Miss dans le cache de requête, puis interroge la base de données et réécrit les données renvoyées dans le cache;
(3) Demande d'écriture pour mettre à jour la base de données.
Tout au long du processus, on constate que l'âge de la base de données est de 20 ans et celui du cache est de 18 ans. Les données du cache et de la base de données sont incohérentes et le cache contient des données sales.
Troisième étape: mettez d'abord à jour la base de données, puis supprimez le cache
Dans le système actuel, il est recommandé de mettre à jour la base de données, puis de supprimer le cache pour les demandes d'écriture, mais il y a encore des problèmes en théorie. Prenons l'exemple suivant pour illustrer.
Mettez d'abord à jour la base de données, puis supprimez le cache
Le processus d'exécution comme indiqué dans la figure ci-dessus:
(1) Demande de lecture Commencez par interroger le cache, si le cache manque, interrogez la base de données pour renvoyer des données;
(2) demande d'écriture pour mettre à jour la base de données et supprimer le cache;
(3) cache de réécriture de demande de lecture;
Grâce au fonctionnement de l'ensemble du processus, on constate que l'âge de la base de données est de 20 ans et celui du cache est de 18 ans, c'est-à-dire que la base de données et le cache sont incohérents, ce qui oblige l'application à lire les données du cache en tant qu'anciennes données.
Mais si nous y réfléchissons attentivement, la probabilité des problèmes ci-dessus est en fait très faible, car les opérations de mise à jour de la base de données prennent généralement plusieurs ordres de grandeur plus longtemps que les opérations de mémoire. La dernière étape de la figure ci-dessus permet de réécrire dans le cache (définir l'âge de 18 ans ) est très rapide, généralement Complet avant la mise à jour de la base de données.
Et si cette scène extrême apparaissait? Nous devons penser à une solution: le délai d'expiration de l'ensemble de données du cache. Habituellement, dans le système, une petite quantité de données peut sembler incohérente pendant une courte période.
Lire à travers
En mode de mise à jour Cache Aside, le code de l'application doit gérer deux sources de données: l'une est le cache et l'autre la base de données. Dans le cadre de la stratégie Read-Through, l'application n'a pas besoin de gérer le cache et la base de données, et doit uniquement déléguer la synchronisation de la base de données au fournisseur de cache Cache Provider. Toutes les interactions de données se font via la couche de cache abstraite.
Processus de lecture
Comme le montre la figure ci-dessus, l'application n'a besoin d'interagir qu'avec le fournisseur de cache et ne se soucie pas de savoir si elle est extraite du cache ou de la base de données.
Lorsqu'un grand nombre de lectures est effectué, la lecture directe peut réduire la charge sur la source de données et a également un certain degré de résilience à l'échec du service de cache. Si le service de cache est en panne, le fournisseur de cache peut toujours fonctionner en accédant directement à la source de données.
La lecture directe convient aux scénarios dans lesquels les mêmes données sont demandées plusieurs fois. Cela est très similaire à la stratégie Cache-Aside, mais il existe encore des différences entre les deux. Là encore:
- Dans Cache-Aside, l'application est chargée d'obtenir les données de la source de données et de les mettre à jour dans le cache.
- En lecture directe, cette logique est généralement prise en charge par un fournisseur de cache indépendant.
Écrivez à travers
Dans le cadre de la stratégie d'écriture immédiate, lorsqu'une mise à jour de données (écriture) se produit, le fournisseur de cache Cache Provider est responsable de la mise à jour de la source de données et du cache sous-jacents.
Le cache est cohérent avec la source de données et atteint toujours la source de données via la couche de cache abstraite lors de l'écriture.
Le fournisseur de cache agit comme un proxy.
Processus d'écriture
Ecrire derrière
L'écriture différée est également appelée réécriture à certains endroits. La simple compréhension est que lorsque l'application met à jour les données, seul le cache est mis à jour et le fournisseur de cache actualise les données dans la base de données à intervalles réguliers. Pour le dire franchement, c'est une écriture différée.
Écrire derrière le processus
Comme le montre la figure ci-dessus, l'application met à jour les deux données, le fournisseur de cache écrira immédiatement dans le cache, mais sera écrit dans la base de données par lots après un certain temps.
Cette approche présente des avantages et des inconvénients:
- L'avantage est que la vitesse d'écriture des données est très rapide, adaptée aux scénarios d'écriture fréquents.
- L'inconvénient est que le cache et la base de données ne sont pas fortement cohérents, alors utilisez-les avec prudence dans les systèmes qui nécessitent une cohérence élevée.
en conclusion
Après avoir tellement appris, je pense que tout le monde a une compréhension claire de la stratégie de mise à jour du cache. Enfin, je résumerai brièvement.
Il existe trois stratégies principales de mise à jour du cache:
- Cache de côté
- Lecture / écriture
- Ecrire derrière
Le cache de côté met généralement à jour la base de données d'abord, puis supprime le cache. Pour le savoir, il définit généralement l'heure du cache des données.
La lecture / écriture est généralement fournie par un fournisseur de cache pour les opérations de lecture et d'écriture externes, et les applications n'ont pas besoin de déterminer si l'opération est un cache ou une base de données.
La simple compréhension de l'écriture différée est de retarder l'écriture. Le fournisseur de cache entre dans la base de données par lots à intervalles réguliers. L'avantage est que la vitesse d'écriture de l'application est très rapide.
D'accord, allons-y aujourd'hui. Avez-vous appris?
Lien d'origine: https://mp.weixin.qq.com/s?__biz=MzIwODI1OTk1Nw==&mid=2650322566&idx=1&sn=2142fe29c6a32e5a2100f4f39ee8953d
Si vous pensez que cet article vous est utile, vous pouvez suivre mon compte officiel et répondre au mot-clé [Interview] pour obtenir une compilation des points de connaissances de base Java et un coffret cadeau d'entrevue! Il y a plus d'articles techniques de produits secs et de matériaux connexes à partager, laissez tout le monde apprendre et progresser ensemble!
