Apprentissage recommandé : Tutoriel vidéo Redis
S'il s'agit d'une mise à jour et qu'il y a un problème de transaction distribuée, le cache peut être modifié et la modification de la base de données peut échouer. Si vous supprimez simplement le cache, même si la modification de la base de données échoue, la requête suivante récupérera directement les données de la base de données et aucune donnée sale n'apparaîtra.
C'est-à-dire que lors de l'ajout, de la suppression ou de la modification d'une classe d'entité, le cache de la classe d'entité doit être vidé. La position d'effacement est avant et après la méthode de fonctionnement de la base de données.
Supprimer uniquement en premier

Supprimer uniquement plus tard
Ainsi, on peut conclure qu'il y a des problèmes avec les deux pré-suppression et post-suppression. La stratégie de double suppression retardée est donc adoptée
C'est encore une preuve par contradiction. La situation dans l'image ci-dessous est une situation dans laquelle l'ancien cache existe toujours après une double suppression. Le délai consiste à garantir que les modifications du cache des autres transactions ont été terminées avant de modifier la base de données -> vider le cache.
Supplément : Pourquoi devrions-nous retarder la double suppression pour assurer la cohérence du cache ? : Il s'agit de garantir que pendant l'intervalle entre la modification des données de la base de données et la suppression des données Redis, s'il y a un succès, il est garanti que cela les données n'existent pas dans Redis. Sans cette suppression, lorsque les données de la base de données ont été modifiées, les anciennes données peuvent toujours être lues à partir de Redis, ce qui entraîne une incohérence des données. La deuxième suppression a lieu après la modification des données de la base de données. À ce stade, les données correspondantes dans redis doivent être à nouveau supprimées. Cette fois, il s'agit de supprimer les données entre la première suppression de redis et la modification des données de la base de données. est une demande, alors les anciennes données seront à nouveau supprimées. Elles seront remises en cache dans Redis, mais les données de la base de données seront ensuite modifiées. Si elles ne sont pas supprimées cette fois, les anciennes données de la base de données existeront dans. redis.
Alors pourquoi devez-vous retarder la suppression de Redis pendant un certain temps après la deuxième modification de la base de données ? Afin d'attendre la lecture précédente de la base de données, attendez que les données soient écrites dans le cache, et enfin supprimez les données sales, c'est donc le moment où les données sont envoyées de la base de données au serveur + écriture du cacheDans le même temps, afin de garantir que le cache sera supprimé, vous pouvez utiliser mq pour garantir que le cache sera supprimé
Si le message n'est pas consommé à plusieurs reprises dans mq, il sera transmis à d'autres. consommateurs pour la consommation (le cache sera supprimé) Apprentissage recommandé :Tutoriel vidéo 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!