Autres - - analyse de la cohérence en double écriture entre redis et MySQL

Un. Préface

Tout d'abord,,Cache en raison de ses caractéristiques de haute concurrence et de haute performance,A été largement utilisé dans les projets.En lisant le cache,Tout le monde n'a aucun doute,Toutes les opérations commerciales sont effectuées selon le processus ci - dessous

Mais en termes de mise à jour du cache,Pour mettre à jour la base de données,Mise à jour du cache,Ou supprimer le cache.Ou supprimer le cache en premier,Mise à jour de la base de données,En fait, tout le monde est très controversé
Cet article se compose des trois parties suivantes 1、Expliquer la politique de mise à jour du cache 2、Analyse des lacunes de chaque stratégie 3、Proposer des améliorations pour remédier aux lacunes

2. Programme de cohérence

Donnez d'abord une explication.,En théorie,,Définir un délai d'expiration pour le cache,Est la solution pour garantir la cohérence finale.Dans le cadre de ce programme,Nous pouvons définir un délai d'expiration pour les données mises en cache,Toutes les opérations d'écriture sont soumises à la base de données,Faites de votre mieux pour les opérations de cache.C'est - à - dire, si la base de données est écrite avec succès,Échec de la mise à jour du cache,Alors, il suffit d'arriver à l'expiration,La demande de lecture suivante lira naturellement la nouvelle valeur de la base de données et remplira le cache.Donc,, Les idées discutées ci - dessous ne dépendent pas du schéma de fixation d'un délai d'expiration pour le cache . Ici,On en discute.TroisMettre à jour la politique：

• 1. Mettre à jour d'abord la base de données,Mise à jour du cache
• 2. Supprimer d'abord le cache,Mise à jour de la base de données
• 3. Mettre à jour d'abord la base de données,Supprimer à nouveau le cache

Trois Mettre à jour d'abord la base de données,Mise à jour du cache

Ce programme,Tout le monde est contre..Pourquoi?？Il y a deux raisons:.
Cause 1（Angle de sécurité du fil） Il y a aussi une demandeAEt demandesBEffectuer une opération de mise à jour,Alors ça va arriver

• （1）ThreadAMise à jour de la base de données
• （2）ThreadBMise à jour de la base de données
• （3）ThreadBMise à jour du cache
• （4）ThreadAMise à jour du cache

Il y a une demandeAMettre à jour le cache devrait être plus que demandéBMise à jour du cache depuis longtemps,Mais pour des raisons comme le réseau,BMais plus queAMise à jour du cache plus tôt.Ce qui conduit à des données sales,Il n'est donc pas tenu compte de.
Cause 2（Perspective du scénario d'affaires） Il y a deux points：

• （1）Si vous écrivez plus de scénarios de base de données,Il y a moins de besoins opérationnels pour lire les scénarios de données,L'adoption d'une telle approche conduit à,Les données n'ont pas encore été lues.,Le cache est mis à jour fréquemment,Performance des déchets.
• （2）Si vous écrivez des valeurs dans la base de données,N'est pas écrit directement dans le cache,Au lieu de cela, il faut une série de calculs complexes pour écrire dans le cache.Alors,Après chaque écriture dans la base de données,Calcule à nouveau la valeur du cache d'écriture,C'est un gaspillage de performance..Apparemment.,Supprimer le cache est plus approprié.

La discussion qui suit est la plus controversée,Supprimer le cache en premier,Mise à jour de la base de données.Ou mettre à jour la base de données en premier,Problème de suppression du cache.

Quatre Supprimer le cache en premier,Mise à jour de la base de données

La raison pour laquelle le programme peut entraîner des incohérences est que.Il y a aussi une demandeAEffectuer une opération de mise à jour,Une autre demandeBEffectuer l'opération de requête.Ce qui suit se produit::

• （1）DemandeAPour écrire,Supprimer le cache
• （2）DemandeBLa requête a trouvé que le cache n'existe pas
• （3）DemandeBAller à la requête de base de données pour obtenir les anciennes valeurs
• （4）DemandeBÉcrire les anciennes valeurs dans le cache
• （5）DemandeAÉcrire une nouvelle valeur dans la base de données Ce qui précède peut entraîner une incohérence.Et,Si la politique d'expiration du cache n'est pas appliquée,Les données sont toujours sales..

Alors,Comment le résoudre?？Adopter une stratégie de double suppression retardée Le pseudocode est le suivant:

public void write(String key,Object data){
redis.delKey(key);
db.updateData(data);
Thread.sleep(1000);
redis.delKey(key);
}

En chinois, c'est

• （1）Éliminer d'abord le cache
• （2）Réécrire la base de données（Ces deux étapes sont les mêmes qu'avant.）
• （3）Dormance1Secondes,Éliminer à nouveau le cache Fais - le.,Vous pouvez1Données sales du cache en secondes,Supprimer à nouveau.

Alors,C'est1Comment est - ce possible?,Combien de temps faut - il dormir?？
Pour la situation ci - dessus,Les lecteurs devraient évaluer eux - mêmes le temps consacré à la lecture de la logique opérationnelle des données de leur projet.Ensuite, le temps d'hibernation pour écrire les données est basé sur le temps de lecture de la logique d'affaires des données,Plus quelques centaines.msC'est tout..Le but de cette action,Est de s'assurer que la demande de lecture est terminée,Write request supprime les données sales du cache causées par read request.
Si vous utilisezmysqlEt l'architecture de séparation lecture - écriture pour？
ok,Dans ce cas,,Les raisons de l'incohérence des données sont les suivantes:,Encore deux demandes.,Une demandeAEffectuer une opération de mise à jour,Une autre demandeBEffectuer l'opération de requête.

• （1）DemandeAPour écrire,Supprimer le cache
• （2）DemandeALes données ont été écrites dans la base de données,
• （3）DemandeBDécouverte du cache de requête,Le cache n'a pas de valeur
• （4）DemandeBPour interroger à partir de la bibliothèque,À ce moment - là,,La synchronisation maître - esclave n'est pas terminée,Donc la requête est une ancienne valeur
• （5）DemandeBÉcrire les anciennes valeurs dans le cache
• （6）Synchronisation maître - esclave complète de la base de données,Passer de la bibliothèque à une nouvelle valeur Ce qui précède,C'est pourquoi les données sont incohérentes..Ou utiliser une double stratégie de suppression et de retard.C'est juste...,Le temps de sommeil est modifié en fonction du délai de synchronisation maître - esclave,Plus quelques centaines.ms.

Adopter cette stratégie d'élimination synchrone,Et la réduction du débit?？
ok,Alors la deuxième suppression est asynchrone.Démarrer un thread par vous - même,Suppression asynchrone.Voilà.,Les demandes écrites n'ont pas besoin de dormir longtemps après,Retour en arrière.Fais - le.,Augmenter le débit.
Deuxième suppression,Et si la suppression échoue？
C'est une très bonne question,Parce que la deuxième suppression a échoué,Ce qui suit se produit.Il y a encore deux demandes,Une demandeAEffectuer une opération de mise à jour,Une autre demandeBEffectuer l'opération de requête,Pour plus de commodité,Supposons qu'il s'agisse d'une seule bibliothèque：

• （1）DemandeAPour écrire,Supprimer le cache
• （2）DemandeBLa requête a trouvé que le cache n'existe pas
• （3）DemandeBAller à la requête de base de données pour obtenir les anciennes valeurs
• （4）DemandeBÉcrire les anciennes valeurs dans le cache
• （5）DemandeAÉcrire une nouvelle valeur dans la base de données
• （6）DemandeATentative de supprimer la demandeBÉcrire à la valeur du cache,Le résultat a échoué. ok,Ce qui veut dire.Si la deuxième suppression du cache échoue,Les incohérences entre le cache et la base de données réapparaissent. Comment le résoudre?？ Solutions spécifiques, Regardez le blogueur sur la (3)Résolution des politiques de mise à jour.

Cinq Mettre à jour d'abord la base de données,Supprimer le cache à nouveau

Tout d'abord,,D'abord.L'étranger a proposé une suite de mise à jour de cache,Il s'appelle《Cache-Aside pattern》.Il y est dit:

1. Échec：L'application commence parcacheAccès aux données,Je n'ai pas,Extraire les données de la base de données,Après le succès,Mise en cache.
2. Hit：Application decacheDonnées extraites,Retour après récupération.
3. Mise à jour：Enregistrer d'abord les données dans la base de données,Après le succès,Désactiver le cache.

En plus,Sites de réseautage social bien connusfacebookAussi dans la thèse《Scaling Memcache at Facebook》Proposé par,Ils ont également mis à jour la base de données en premier,La politique de suppression du cache.
Il n'y a pas de problème de concurrence dans cette situation?？
C'est faux..Supposons qu'il y ait deux demandes,Une demandeAFaire une requête,Une demandeBMise à jour,Il y a donc les situations suivantes:
（1）Le cache a juste échoué
（2）DemandeAInterrogation de la base de données,Une vieille valeur.
（3）DemandeBÉcrire une nouvelle valeur dans la base de données
（4）DemandeBSupprimer le cache
（5）DemandeAÉcrire les anciennes valeurs trouvées dans le cache ok,Si cela se produit,Il y a des données sales..
Et pourtant,Quelle est la probabilité que cela se produise?？
Il y a une condition congénitale,C'est l'étape.（3）Étapes du rapport d'opération de la base de données d'écriture pour（2）La lecture de la base de données prend moins de temps,C'est ce qui rend possible（4）Avant les étapes（5）.
Mais...,Réfléchissez.,Les opérations de lecture de la base de données sont beaucoup plus rapides que les opérations d'écriture（Pourquoi faire une séparation lecture - écriture?,Le sens de la séparation lecture - écriture est que la lecture est plus rapide,Faible consommation de ressources）,Donc les étapes（3）Étapes du rapport temps / temps（2）Plus court,C'est une situation difficile.. Hypothèses,Quelqu'un doit lever la barre.,J'ai un trouble obsessionnel - compulsif.,Il faut s'en occuper.？
Comment résoudre les problèmes de concurrence susmentionnés？
Tout d'abord,,C'est un scénario pour donner un temps de disponibilité au cache.Deuxièmement,,Adopter une stratégie（2）La politique asynchrone de suppression des délais donnée dans,Une fois la demande de lecture terminée,Effectuer une autre opération de suppression.
Y a - t - il d'autres causes d'incohérence？
Oui.,C'est aussi la politique de mise à jour du cache（2）Et la politique de mise à jour du cache（3）Il y a un problème,Et si la suppression du cache échoue,N'y a - t - il pas une incohérence.Comme une demande d'écriture de données,Et écrit dans la base de données,Impossible de supprimer le cache,Il y aura des incohérences.C'est aussi la politique de mise à jour du cache（2）La dernière question que j'ai laissée.
Comment résoudre？ Fournir un mécanisme de retry garanti,Voici deux options.
Programme I： Comme le montre la figure ci - dessous

Le processus est le suivant:

• （1）Mettre à jour les données de la base de données;
• （2）La suppression du cache a échoué en raison de divers problèmes
• （3）À supprimerkeyEnvoyer à la file d'attente des messages
• （4）Consommer des nouvelles par soi - même,Obtenir ce qui doit être supprimékey
• （5）Reprendre l'opération de suppression,Jusqu'à ce que ça marche. Et pourtant,Le programme présente un inconvénient,Une intrusion massive dans les codes des secteurs d'activité.Il y a donc le deuxième plan,Dans le Programme II,Démarrer un abonné pour s'abonner à la base de donnéesbinlog,Obtenir les données nécessaires.Dans la demande,Un autre programme,Obtenez des informations de ce programme d'abonnement,Pour supprimer le cache.

Programme II：

Le processus est illustré dans la figure ci - dessous.：

• （1）Mettre à jour les données de la base de données
• （2）La base de données écrira des informations opérationnellesbinlogDans le journal
• （3）Le Programme d'abonnement extrait les données requises etkey
• （4）Un autre code non commercial,Obtenir cette information
• （5）Tentative de supprimer l'opération cache,La suppression de Discovery a échoué
• （6）Envoyer cette information à la file d'attente des messages
• （7）Récupérer les données de la file d'attente des messages,Retry Operation.

**Notes：**Abonnement ci - dessusbinlogLa procédure est la suivante:mysqlIl y a un intergiciel prêt à l'emploi appelécanal,L'abonnement peut être complétébinlogFonction du Journal.Quant àoracleMoyenne, Les blogueurs ne savent pas actuellement s'il existe un intergiciel disponible sur le marché .En plus,Mécanisme de retry, Les blogueurs utilisent la file d'attente des messages .Si les exigences de conformité ne sont pas très élevées,Un autre thread directement dans le programme,Réessayez à intervalles réguliers,Tout le monde peut jouer librement,Juste une idée.

Fonction.Quant àoracleMoyenne, Les blogueurs ne savent pas actuellement s'il existe un intergiciel disponible sur le marché .En plus,Mécanisme de retry, Les blogueurs utilisent la file d'attente des messages .Si les exigences de conformité ne sont pas très élevées,Un autre thread directement dans le programme,Réessayez à intervalles réguliers,Tout le monde peut jouer librement,Juste une idée.