Comment Redis met à jour le cache

Il existe quatre modèles de conception pour le cache de mise à jour Redis : Cache mis à part, Lecture complète, Écriture complète, Écriture derrière la mise en cache Examinons ces quatre modèles un par un.

Modèle de cache de côté

C'est le modèle le plus couramment utilisé. La logique spécifique est la suivante : (Apprentissage recommandé : Tutoriel vidéo Redis)

Échec : L'application récupère d'abord les données du cache. Si elle ne les obtient pas, elle. obtiendra les données de la base de données. Après succès, mettez-les dans le cache.

Hit : L'application récupère les données du cache et revient après les avoir récupérées.

Mise à jour : enregistrez d'abord les données dans la base de données, puis invalidez le cache après succès.

Notez que notre mise à jour consiste d'abord à mettre à jour la base de données, puis à invalider le cache après succès. Alors, cette méthode peut-elle éviter le problème mentionné plus haut dans l’article ? Nous pouvons le comprendre.

L'une est l'opération de requête et l'autre est la simultanéité de l'opération de mise à jour. Tout d'abord, il n'y a pas d'opération pour supprimer les données du cache, mais les données de la base de données sont mises à jour en premier. , le cache est toujours valide, donc la concurrence L'opération de requête prend des données qui n'ont pas été mises à jour.

Cependant, l'opération de mise à jour invalide immédiatement le cache et les opérations de requête ultérieures extraient les données de la base de données. Contrairement au problème de logique présenté au début de l'article, les opérations de requête ultérieures récupéreront toujours les anciennes données.

Read Through

La routine Read Through consiste à mettre à jour le cache pendant l'opération de requête, c'est-à-dire lorsque le cache expire (expiration ou échange LRU), Cache Aside est la responsabilité de l'appelant de charger les données dans le cache, tandis que Read Through utilise le service de cache pour les charger lui-même, de sorte qu'il est transparent pour l'application.

Write Through

La routine Write Through est similaire à Read Through, mais elle se produit lorsque les données sont mises à jour. Lorsque les données sont mises à jour, si le cache n'est pas atteint, la base de données est directement mise à jour puis renvoyée. Si le cache est atteint, le cache est mis à jour, puis le cache lui-même met à jour la base de données (il s'agit d'une opération synchrone)

L'image ci-dessous provient de l'entrée Cache de Wikipédia. Vous pouvez comprendre la mémoire comme la base de données dans notre exemple.

Modèle de mise en cache d'écriture derrière

Write Behind est également appelé Write Back. Certains étudiants qui connaissent le noyau du système d'exploitation Linux devraient être très familiers avec la réécriture. N'est-ce pas l'algorithme Page Cache du système de fichiers Linux ? Oui, vous voyez, les bases sont toutes les mêmes. C’est pourquoi la fondation est très importante, je ne l’ai pas dit une seule fois auparavant.

Routine Write Back, en un mot, lors de la mise à jour des données, seul le cache est mis à jour, pas la base de données, et notre cache mettra à jour la base de données de manière asynchrone par lots.

L'avantage de cette conception est qu'elle rend les opérations d'E/S de données extrêmement rapides (car elle opère directement sur la mémoire). Parce qu'elle est asynchrone, l'écriture arrière peut également fusionner plusieurs opérations sur les mêmes données, donc). l'amélioration des performances est assez impressionnante.

Cependant, le problème que cela pose est que les données ne sont pas fortement cohérentes et peuvent être perdues (nous savons qu'un arrêt anormal d'Unix/Linux entraînera une perte de données, à cause de cela).

Dans la conception de logiciels, il nous est fondamentalement impossible de créer une conception sans défauts, tout comme le temps est échangé contre de l'espace dans la conception d'algorithmes, et l'espace est échangé contre du temps. Parfois, une forte cohérence et des performances élevées, élevées. la disponibilité et les hautes performances sont en conflit. La conception de logiciels a toujours été une question de compromis.

De plus, la logique de mise en œuvre de Write Back est relativement complexe, car elle doit suivre quelles données ont été mises à jour et doivent être vidées vers la couche de persistance. La réécriture du système d'exploitation ne sera véritablement persistante que lorsque le cache doit être invalidé, par exemple lorsque la mémoire n'est pas suffisante, ou lorsque le processus se termine, etc. C'est également ce qu'on appelle l'écriture paresseuse.

Il existe un organigramme de réécriture sur wikipedia. La logique de base est la suivante :

Pour plus d'articles techniques liés à Redis, veuillez visiter Prise en main de Redis Learn dans la colonne tutoriel  !

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!