Comment Redis maintient la cohérence avec MySQL

Il existe deux façons de maintenir la cohérence entre Redis et MySQL, à savoir : 1. Effectuer l'opération [redis.del(key)] avant et après l'écriture de la base de données et définir un délai d'attente raisonnable 2. Grâce à ; Le mécanisme de synchronisation basé sur l'abonnement à binlog assure la cohérence entre Redis et MySQL.

La méthode pour maintenir la cohérence entre Redis et MySQL consiste à adopter une stratégie de double suppression retardée, à supprimer d'abord le cache, puis à écrire dans la base de données ; consiste à mettre à jour le cache de manière asynchrone. Lisez d'abord Redis, puis écrivez MySQL, puis mettez à jour les données Redis

La solution de cohérence du cache et de la base de données est la suivante :

Méthode 1 : utiliser la stratégie de double suppression différée

Effectuez l'opération redis.del(key) avant et après l'écriture de la base de données et définissez un délai d'attente raisonnable.

Le pseudo code est le suivant

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

Les étapes spécifiques sont :

(1) Supprimez d'abord le cache

( 2) Ensuite, écrivez la base de données

(3) Mettez en veille pendant 500 millisecondes

(4) Supprimez à nouveau le cache

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

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 prend également 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.

Définir le délai d'expiration du cache

Théoriquement, définir le délai d'expiration du cache est une solution pour assurer 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.

Inconvénients de cette solution

Combiné avec 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, et des les écritures sont ajoutées. Le temps nécessaire à la requête.

Méthode 2 : Cache de mise à jour asynchrone (mécanisme de synchronisation basé sur le binlog d'abonnement)

Idée technique globale :

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

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

2) Écriture de MySQL : les ajouts, suppressions et modifications sont toutes des opérations sur MySQL

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

Mise à jour Redis

(1) Les opérations de données sont principalement divisées en deux blocs majeurs :

L'un est plein (écrire toutes les données dans Redis en même temps) et l'autre est incrémentiel (mise à jour en temps réel)

Ce dont nous parlons ici est incrémentiel, ce qui fait référence pour mettre à jour et insérer MySQL, supprimez les données modifiées.

(2) Après avoir lu le binlog, analysez-le et utilisez la file d'attente de messages pour pousser 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), via lequel vous pouvez vous abonner au binlog de MySQL, et canal imite la demande de sauvegarde de la base de données esclave de MySQL pour mettre à jour les données Redis.

Bien sûr, vous pouvez également utiliser d'autres tiers pour les outils de transmission de messages ici : 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!