Où configurer la politique de nettoyage du cache dans Redis

Lors de l'utilisation de Redis comme cache, si l'espace mémoire est plein, les anciennes données seront automatiquement expulsées. Memcached fonctionne de cette façon par défaut et la plupart des développeurs le connaissent. (Apprentissage recommandé : Tutoriel vidéo Redis)

LRU est le seul algorithme de recyclage pris en charge par Redis. Cet article présente en détail l'instruction maxmemory utilisée pour limiter l'utilisation maximale de la mémoire et l'explique en profondeur. ce que Redis utilise. Algorithme LRU approximatif.

directive de configuration maxmemory

maxmemory est utilisée pour spécifier la mémoire maximale que Redis peut utiliser. Il peut être défini dans le fichier redis.conf ou modifié dynamiquement pendant le fonctionnement via la commande CONFIG SET.

Par exemple, pour définir une limite de mémoire de 100 Mo, vous pouvez la configurer dans le fichier redis.conf comme ceci :

maxmemory 100mb

Définissez maxmemory sur 0, ce qui signifie qu'il n'y a pas de mémoire limite. Bien entendu, il existe une limitation implicite pour les systèmes 32 bits : jusqu'à 3 Go de RAM.

Lorsque l'utilisation de la mémoire atteint la limite maximale, si de nouvelles données doivent être stockées, Redis peut directement renvoyer un message d'erreur ou supprimer certaines anciennes données en fonction des politiques configurées.

Politique d'expulsion

Lorsque la limite de mémoire maximale (maxmemory) est atteinte, Redis décide du comportement spécifique en fonction de la politique configurée par maxmemory-policy.

La version actuelle, les stratégies prises en charge par Redis 3.0 incluent :

noeviction : Ne supprimez pas la stratégie lorsque la limite maximale de mémoire est atteinte, si. plus de mémoire est nécessaire, renvoie directement le message d'erreur. La plupart des commandes d'écriture entraîneront une occupation de plus de mémoire (à de rares exceptions près, telles que DEL).

allkeys-lru : commun à toutes les clés ; supprimez d'abord les clés les moins récemment utilisées (LRU).

volatile-lru : limité uniquement à la partie où l'expiration est définie ; supprimez d'abord la clé la moins récemment utilisée (LRU).

allkeys-random : Commun à toutes les clés ; supprime aléatoirement certaines clés.

volatile-random : limité uniquement à la partie où l'expiration est définie ; supprimez aléatoirement certaines clés.

volatile-ttl : limité uniquement à la partie où l'expiration est définie ; les clés avec un temps restant court (durée de vie, TTL) seront supprimées en premier.

Si la clé d'expiration n'est pas définie et que les conditions préalables ne sont pas remplies ; alors le comportement des stratégies volatile-lru, volatile-random et volatile-ttl est fondamentalement le même que celui de la noeviction (pas de suppression).

Vous devez choisir une stratégie d'expulsion appropriée en fonction des caractéristiques du système. Bien entendu, vous pouvez également définir dynamiquement la politique d'expulsion via des commandes pendant le fonctionnement et surveiller les échecs et les accès au cache via la commande INFO pour le réglage.

De manière générale :

S'il est divisé en données chaudes et données froides, il est recommandé d'utiliser la stratégie allkeys-lru. Autrement dit, certaines clés sont souvent lues et écrites. Si vous n'êtes pas sûr des caractéristiques spécifiques de l'entreprise, alors allkeys-lru est un bon choix.

Si vous devez lire et écrire toutes les clés en boucle, ou si la fréquence d'accès de chaque clé est similaire, vous pouvez utiliser la stratégie allkeys-random, c'est-à-dire que la probabilité de lire et d'écrire tous les éléments est presque pareil.

Si vous souhaitez que Redis filtre les clés qui doivent être supprimées en fonction de la durée de vie, veuillez utiliser la stratégie volatile-ttl.

Les principaux scénarios d'application des stratégies volatile-lru et volatile-random sont : les instances avec à la fois du cache et des clés persistantes. De manière générale, pour des scénarios comme celui-ci, deux instances Redis distinctes doivent être utilisées.

Il convient de mentionner que la définition de l'expiration consommera de la mémoire supplémentaire, donc l'utilisation de la stratégie allkeys-lru peut faire une utilisation plus efficace de la mémoire, car de cette manière, le délai d'expiration ne peut plus être défini.

La mise en œuvre interne de l'expulsion

Le processus d'expulsion peut être compris ainsi :

Le client exécute une commande, ce qui entraîne une augmentation des données Redis et une utilisation plus importante de la mémoire.

Redis vérifie l'utilisation de la mémoire si elle dépasse la limite maximale de mémoire, certaines clés seront effacées conformément à la politique.

Passer à la commande suivante, et ainsi de suite.

Pendant ce processus, l'utilisation de la mémoire continuera à atteindre la valeur limite, puis la dépassera, puis supprimera certaines clés, et l'utilisation retombera en dessous de la valeur limite.

Si une certaine commande entraîne une utilisation importante de la mémoire (comme la sauvegarde d'un grand ensemble via une nouvelle clé), l'utilisation de la mémoire peut dépasser considérablement la limite de mémoire maximale pendant un certain temps.

Algorithme LRU approximatif

Redis n'utilise pas l'algorithme LRU complet. La clé automatiquement expulsée n'est pas nécessairement celle qui satisfait le mieux aux caractéristiques LRU. Au lieu de cela, un petit nombre d'échantillons de clé sont extraits via l'algorithme LRU approximatif, puis la clé avec le temps d'accès le plus ancien est supprimée.

L'algorithme d'expulsion a été grandement optimisé depuis Redis 3.0, en utilisant pool comme candidat. Cela améliore considérablement l'efficacité de l'algorithme et est plus proche du véritable algorithme LRU.

Dans l'algorithme LRU de Redis, la précision de l'algorithme peut être ajustée en définissant le nombre d'échantillons. Configurez via la commande suivante :

maxmemory-samples 5

Pourquoi ne pas utiliser l'implémentation complète de LRU La raison est d'économiser de la mémoire ? Mais le comportement de Redis est fondamentalement équivalent à celui de LRU. Ce qui suit est un tableau de comparaison comportementale entre Redis LRU et l'algorithme LRU complet.

Pendant le processus de test, l'accès commence à partir de la première clé, la première clé est donc le meilleur objet d'expulsion.

Vous pouvez voir trois types de points sur l'image, formant trois bandes différentes.

La partie gris clair indique l'objet expulsé.

La partie grise représente les objets "non expulsés".

La partie verte indique les objets ajoutés ultérieurement.

Dans l'implémentation pure de l'algorithme LRU, la première moitié des anciennes clés est libérée. L'algorithme LRU de Redis ne libère que des clés plus longues de manière probabiliste.

Comme vous pouvez le constater, dans Redis 3.0, l'effet de 5 échantillons est bien meilleur que celui de Redis 2.8. Bien sûr, Redis 2.8 est également bon, la dernière clé consultée est essentiellement toujours en mémoire. Lors de l'utilisation de 10 échantillons dans Redis 3.0, elle est très proche de l'algorithme LRU pur.

Notez que LRU n'est qu'un modèle de probabilité utilisé pour prédire qu'une certaine clé pourra continuer à être consultée dans le futur. De plus, si la situation d'accès aux données est conforme à une distribution de loi de puissance, alors pour la plupart des requêtes, LRU fonctionnera bien.

Dans la simulation, nous avons constaté que si l'accès selon la loi de puissance est utilisé, les résultats du LRU pur et du Redis sont très différents, voire invisibles.

Bien sûr, vous pouvez également augmenter le nombre d'échantillons à 10, au prix d'une consommation de CPU supplémentaire, afin que les résultats soient plus proches du LRU réel, et que la différence puisse être jugée grâce aux statistiques d'absence de cache. .

Il est facile de définir la taille de l'échantillon, utilisez la commande CONFIG SET maxmemory-samples

Pour plus d'articles techniques liés à Redis, veuillez visiter le Tutoriel de démarrage de Redis chronique Allez étudier !

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!