Méthodes de cohérence du cache Redis et des données MySQL

Cause de la demande

Dans les scénarios commerciaux à forte concurrence, la base de données constitue dans la plupart des cas le maillon le plus faible pour l’accès des utilisateurs simultanés. Par conséquent, vous devez utiliser redis pour effectuer une opération de mise en mémoire tampon afin que la requête puisse d'abord accéder à redis au lieu d'accéder directement à des bases de données telles que MySQL.

Ce scénario métier résout principalement le problème de lecture des données du cache Redis. Les opérations commerciales sont généralement effectuées selon le processus de la figure ci-dessous.

Il n'y a généralement aucun problème lors de la lecture de l'étape du cache, mais une fois qu'elle implique des mises à jour des données : mises à jour de la base de données et du cache, des problèmes de cohérence des données entre le cache (Redis) et la base de données (MySQL) sont susceptibles de se produire.

Que vous écriviez d'abord dans la base de données MySQL, puis supprimiez le cache Redis ; ou que vous supprimiez d'abord le cache, puis écriviez dans la base de données, une incohérence des données peut se produire. Donnez un exemple :

1. Si le cache Redis est supprimé et qu'un autre thread vient lire avant d'avoir le temps d'écrire dans la base de données MySQL et constate que le cache est vide, il lit les données de la base de données et les écrit dans le cache. , le cache contient des données sales.

2. Si la bibliothèque est écrite en premier et que le thread écrivant la bibliothèque plante avant que le cache ne soit supprimé et que le cache n'est pas supprimé, une incohérence des données se produira également.

Étant donné que l'écriture et la lecture sont simultanées et que l'ordre ne peut pas être garanti, il y aura une incohérence des données entre le cache et la base de données.

Tathagata le résout ? Voici deux solutions, faciles d’abord puis difficiles, choisies en fonction des coûts métiers et techniques.

​Solutions de mise en cache et de cohérence des bases de données

1. La première option : adopter une stratégie de double suppression différée

Effectuez l'opération redis.del (clé) avant et après l'écriture de la bibliothèque et définissez un délai d'attente raisonnable.

Le pseudo code est le suivant

​écriture vide publique (clé de chaîne, données d'objet){

redis.delKey(clé);

​db.updateData(data);

Discussion.sleep(500);

redis.delKey(clé);

}

2. Les étapes spécifiques sont :

​1) Supprimez d'abord le cache

2) Écrivez à nouveau la base de données

3) Dormez pendant 500 millisecondes

4) Supprimez à nouveau le cache

Alors, comment ces 500 millisecondes sont-elles déterminées et pendant combien de temps doit-il dormir ?

Vous devez évaluer la logique métier fastidieuse de lecture des données de votre projet. Le but de ceci est de garantir que la demande de lecture se termine et que la demande d'écriture peut supprimer les données sales mises en cache causées par la demande de lecture.

Bien entendu, cette stratégie doit également prendre en compte la synchronisation fastidieuse entre Redis et la base de données maître-esclave. Le temps de sommeil final pour l'écriture des données : ajoutez quelques centaines de millisecondes au temps nécessaire à la lecture de la logique métier des données. Par exemple : dormir 1 seconde.

​3.Définir le délai d'expiration du cache

Théoriquement, fixer un délai d'expiration pour le cache est une solution pour garantir une cohérence éventuelle. Toutes les opérations d'écriture sont soumises à la base de données. Tant que le délai d'expiration du cache est atteint, les demandes de lecture ultérieures liront naturellement les nouvelles valeurs de la base de données et rempliront le cache.

4. Inconvénients de ce plan

En combinant la stratégie de double suppression + le paramètre de délai d'expiration du cache, le pire des cas est que les données soient incohérentes pendant le délai d'expiration, ce qui augmente également le temps d'écriture des requêtes.

2. La deuxième solution : cache de mise à jour asynchrone (mécanisme de synchronisation basé sur l'abonnement à binlog)

1. Idée technique globale :

Consommation incrémentielle d'abonnement MySQL binlog + file d'attente de messages + mise à jour incrémentielle des données vers redis

1) Lire Redis : les données chaudes sont essentiellement dans Redis

2) Écriture de MySQL : l'ajout, la suppression et la modification sont toutes des opérations sur MySQL

3) Mettre à jour les données Redis : binlog des opérations de données MySQ à mettre à jour vers Redis

​2.Mise à jour Redis

1) Les opérations sur les données sont principalement divisées en deux blocs :

L'un est à plein volume (écrivez toutes les données sur Redis en même temps)

L'un est incrémentiel (mise à jour en temps réel)

Ce dont nous parlons ici est l'incrément, qui fait référence à la mise à jour, à l'insertion et à la suppression des données modifiées de MySQL.

2) Après avoir lu le binlog, analysez-le et utilisez la file d'attente de messages pour transmettre et mettre à jour les données du cache Redis de chaque station.

De cette façon, une fois que de nouvelles opérations d'écriture, de mise à jour, de suppression et autres se produisent dans MySQL, les messages liés au binlog peuvent être transmis à Redis, et Redis mettra à jour Redis en fonction des enregistrements du binlog.

En fait, ce mécanisme est très similaire au mécanisme de sauvegarde maître-esclave de MySQL, car la sauvegarde maître-esclave de MySQL assure également la cohérence des données via binlog.

Ici, vous pouvez utiliser canal (un framework open source d'Alibaba) en combinaison, grâce auquel vous pouvez vous abonner au binlog de MySQL. Canal imite la demande de sauvegarde de la base de données esclave de MySQL, afin que la mise à jour des données de Redis obtienne le même effet.

Bien sûr, pour l'outil push de messages ici, vous pouvez également utiliser d'autres tiers : kafka, RabbitMQ, etc. pour implémenter les mises à jour push de Redis.

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!