Quelle est la stratégie de mise à jour du cache Redis ?

1. Avantages et coûts de la mise en cache

1.1 Avantages

• Lecture et écriture accélérées : Parce que les caches ont généralement une mémoire pleine (comme Redis, Memcache) et que la couche de stockage a généralement des performances de lecture et d'écriture insuffisantes (telles que comme MySQL), la vitesse de lecture et d'écriture de la mémoire est bien supérieure à celle des E/S disque. L'utilisation du cache peut accélérer efficacement la lecture et l'écriture et optimiser l'expérience utilisateur.

• Réduisez la charge du back-end : Aidez le back-end à réduire les accès (Mysql est défini avec un nombre maximum de connexions. Si un grand nombre d'accès atteignent la base de données en même temps et que les E/S du disque la vitesse est très lente, il est facile de provoquer l'utilisation du nombre maximum de connexions, mais Redis est le plus grand en théorie) et des calculs complexes (tels que des instructions SQL très complexes), ce qui réduit considérablement la charge sur le backend.

1.2 Coût

• Incohérence des données : Il existe une incohérence dans les données de la couche cache et de la couche de stockage dans une certaine fenêtre de temps, et la fenêtre de temps est liée à la stratégie de mise à jour.

• Coût de maintenance du code : Après l'ajout du cache, la logique de la couche cache et de la couche de stockage doit être traitée en même temps, ce qui augmente le coût de maintenance du code pour les développeurs.

• Coûts d'exploitation et de maintenance : Prenons l'exemple de Redis Cluster. Après l'adhésion, les coûts d'exploitation et de maintenance seront augmentés virtuellement.

1.3 Scénarios d'utilisation

• Calculs complexes avec une surcharge élevée : En prenant MySQL comme exemple, certaines opérations ou calculs complexes (tels qu'un grand nombre d'opérations de table conjointes, certains calculs de regroupement), sans mise en cache, non seulement ce n'est pas satisfaisant. Une concurrence élevée apportera également un énorme fardeau à MySQL.

• Accélérer la réponse aux demandes : Même si l'interrogation d'une seule donnée backend est assez rapide, vous pouvez toujours utiliser le cache en prenant Redis comme exemple, il peut effectuer des dizaines de milliers de lectures et d'écritures par seconde, et le. les opérations par lots fournies peuvent optimiser l'ensemble de la chaîne d'E/S. Le temps de réponse

2. Stratégie de mise à jour du cache

2.1 Stratégie d'élimination des débordements de mémoire

Réflexion : Redis dans l'environnement de production perd souvent certaines données Une fois écrit, cela peut disparaître après un certain temps. Quelle est la raison ?

Normalement, le cache Redis est stocké en mémoire, mais étant donné que la mémoire est précieuse et limitée, il est courant d'utiliser des disques volumineux et bon marché pour le stockage. Une machine peut ne disposer que de quelques dizaines de gigaoctets de mémoire, mais peut disposer de plusieurs téraoctets de capacité de disque dur. Redis s'appuie principalement sur la mémoire pour effectuer des opérations de lecture et d'écriture hautes performances et à haute concurrence. Ainsi, comme la mémoire est limitée, par exemple, Redis ne peut utiliser que 10 Go. Que ferez-vous si vous y écrivez 20 Go de données ? Bien entendu, les données 10G seront supprimées, puis les données 10G seront conservées. Quelles données doivent être supprimées ? Quelles données doivent être conservées ? Évidemment, vous devez supprimer les données rarement utilisées et conserver les données fréquemment utilisées. La politique d'expiration de Redis détermine que même si les données ont expiré, elles continueront à occuper la mémoire.

Dans Redis, lorsque la mémoire utilisée atteint la limite supérieure de maxmemory (used_memory>maxmemory), la politique de contrôle de débordement correspondante sera déclenchée. La politique spécifique est contrôlée par le paramètre maxmemory-policy.

Redis prend en charge 6 stratégies :

• noeviction : La stratégie par défaut ne supprimera aucune donnée, rejettera toutes les opérations d'écriture et renverra le message d'erreur client (erreur) La commande OOM n'est pas autorisée lors de l'utilisation de la mémoire, pour le moment Redis uniquement répond aux opérations de lecture

• Selon l'algorithme LRU, supprimez les valeurs clés avec des attributs de délai d'attente (expire) et libérez suffisamment d'espace. S'il n'y a pas d'objets clés supprimables, revenez à la stratégie de non-éviction

• volatile-random : supprimez aléatoirement les clés expirées jusqu'à ce que suffisamment d'espace soit libéré

• allkeys-lru : supprimez les clés selon l'algorithme LRU, que ce soit il y a des données ou non. Définir la propriété timeout jusqu'à ce que suffisamment d'espace soit libéré

• allkeys-random : Supprimer aléatoirement toutes les clés jusqu'à ce que suffisamment d'espace soit libéré (non recommandé)

• volatile-ttl : Basé sur le ttl (temps restant) de l'attribut objet clé-valeur (durée de vie, TTL)), supprimez les données qui expireront récemment. Sinon, revenez à la stratégie de noeviction

LRU : Les moins récemment utilisés, les éléments mis en cache les moins récemment utilisés ont un horodatage, lorsque la capacité du cache est pleine et qu'il faut libérer de l'espace pour mettre en cache de nouveaux éléments, alors l'élément dont l'horodatage est le plus éloigné de l'heure actuelle parmi les éléments de cache existants seront effacés du cache. ​​

La stratégie de contrôle de débordement de mémoire peut être configurée dynamiquement à l'aide du jeu de configuration maxmemory-policy{policy}. Les commandes d'écriture entraînent l'exécution fréquente de récupération de mémoire en cas de débordement de mémoire, ce qui est très coûteux. Dans l'architecture de réplication maître-esclave, la commande de suppression correspondant à l'opération de récupération de mémoire sera synchronisée sur le nœud esclave pour assurer la cohérence des données du maître. et les nœuds esclaves, ce qui entraîne un problème d'amplification d'écriture.

2.2 Stratégie d'expiration

La stratégie d'expiration adoptée par le serveur Redis est : suppression paresseuse + suppression régulière

Suppression paresseuse :

Chaque bibliothèque Redis contient un dictionnaire d'expiration, qui enregistre le délai d'expiration de toutes les clés. Lorsque le client lit une clé, il vérifiera d'abord si la clé a expiré dans le dictionnaire d'expiration. Si la clé a expiré, il effectuera une opération de suppression et reviendra vide. Cette stratégie vise à économiser les coûts du processeur, mais l'utilisation de cette méthode seule pose le problème de fuite de mémoire. Lorsque la clé expirée n'a pas été accédée, elle ne sera pas supprimée à temps, ce qui entraînera la libération de la mémoire à temps.

Suppression planifiée :

Redis maintient une tâche planifiée en interne, par défaut, il exécute 10 analyses d'expiration par seconde (le nombre d'exécutions est modifié via la configuration Hz dans redis.conf). dans le dictionnaire d'expiration. Au lieu de cela, un algorithme adaptatif est utilisé pour recycler les clés en fonction du taux d'expiration des clés et en utilisant deux modes de vitesse :

1 Retirez au hasard 20 clés du dictionnaire expiré
2 Supprimez les clés expirées parmi celles-ci. 20 clés
3 .Si la proportion de clés expirées dépasse 25 %, répétez les étapes 1 et 2

Afin de garantir que l'analyse n'a pas un cycle excessif, elle a exécuté des tâches planifiées de suppression programmée et ne peut pas fournir de services au monde extérieur, provoquant le blocage du thread et augmentant le temps d'analyse, la limite supérieure, la valeur par défaut est de 25 millisecondes (c'est-à-dire qu'en mode lent par défaut, si 25 millisecondes ne sont pas terminées, il passe en mode blocage. Le délai d'attente. en mode est de 1 milliseconde et ne peut être exécuté qu'une fois toutes les 2 secondes. Lorsque le mode lent est terminé, il se terminera normalement et reviendra en mode rapide)

3. Mise à jour de l'application

1. récupère d'abord les données du cache. S'il ne les obtient pas, il obtiendra les données de la base de données. Après succès, mettez-les dans le cache.
2. Supprimez d'abord le cache, puis mettez à jour la base de données : Cette opération pose un gros problème. Une fois le cache supprimé, une demande de lecture est reçue pour mettre à jour les données. À ce moment, le cache est supprimé, la base de données sera donc supprimée. être lu directement. Les données de l'opération de lecture sont anciennes et seront chargées dans le cache. Les demandes de lecture ultérieures accéderont à toutes les anciennes données.
3. Mettez d'abord à jour la base de données, puis supprimez le cache (recommandé). Pourquoi ne pas mettre à jour le cache après avoir écrit dans la base de données ? La raison principale est que deux opérations d'écriture simultanées peuvent provoquer des données sales.

4. Granularité du cache

1 Polyvalence

La mise en cache de toutes les données est plus polyvalente que les données partielles, mais d'après l'expérience réelle, les applications ne nécessitent que quelques attributs importants pendant longtemps.

2 Occuper de l'espace

La mise en cache de toutes les données prend plus d'espace que des données partielles. Il existe les problèmes suivants :

• Toutes les données entraîneront un gaspillage de mémoire.

• Toutes les données peuvent générer une grande quantité de trafic réseau à chaque fois, prendre un temps relativement long et, dans des cas extrêmes, peuvent bloquer le réseau.

• La surcharge du processeur liée à la sérialisation et à la désérialisation de toutes les données est plus importante.

3 Maintenance du code

Les données complètes présentent des avantages évidents, mais si vous souhaitez ajouter de nouveaux champs à certaines données, vous devez modifier le code métier et généralement actualiser les données mises en cache.

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!