21 points que vous devez savoir sur l'utilisation de Redis

Préface

Récemment, j'apprends les connaissances liées à Redis et j'ai lu les spécifications de développement redis d'Ali et le livre de développement et d'exploitation et de maintenance de Redis. Il est divisé en quatre directions: spécifications d'utilisation, commandes ponctuelles, opérations réelles du projet et configuration d'exploitation et de maintenance. J'ai sélectionné 21 points d'attention lors de l'utilisation de Redis. J'espère que cela sera utile à tout le monde. Apprenons ensemble.

Compte public: Le petit garçon ramassant des escargots

1. Spécifications d'utilisation de Redis

1.1, points de spécification clés

Lorsque nous concevons des clés Redis, nous devons prêter attention aux points suivants:

Préfixez le nom de l'entreprise avec la clé et séparez-le par deux points pour éviter que les conflits de clés ne soient écrasés. Par exemple, live: rang: 1

Pour garantir que la sémantique de la clé est claire, la longueur de la clé doit être inférieure à 30 caractères autant que possible.

La clé ne doit pas contenir de caractères spéciaux, tels que des espaces, des sauts de ligne, des guillemets simples et doubles et d'autres caractères d'échappement.

Les clés Redis essaient de définir ttl pour s'assurer que les clés qui ne sont pas utilisées peuvent être nettoyées ou éliminées à temps.

1.2, les principaux points de spécification de la valeur

La valeur de Redis ne peut pas être définie arbitrairement.

Le premier point est que si un grand nombre de bigKeys est stocké, il y aura des problèmes, ce qui entraînera des requêtes lentes, une croissance excessive de la mémoire, etc.

S'il s'agit d'un type String, la taille d'une valeur unique est contrôlée dans les 10 Ko.

Pour les types hash, list, set, zset, le nombre d'éléments ne dépasse généralement pas 5000.

Le deuxième point est de sélectionner le type de données approprié. De nombreux petits partenaires utilisent uniquement le type String de Redis, qui est fourni avec set and get. En fait, Redis fournit une multitude de types de structures de données , et certains scénarios d'entreprise sont plus adaptés pour hash、zsetattendre d'autres résultats de données.

Contre-exemple:

set user:666:name jay
set user:666:age 18
复制代码

Exemple positif

hmset user:666 name jay age 18 
复制代码

1.3. Définissez le délai d'expiration de la clé et faites attention aux clés des différentes entreprises, essayez de répartir un peu le délai d'expiration

Parce que les données Redis sont stockées en mémoire et que les ressources mémoire sont très précieuses.
Nous utilisons généralement Redis comme cache, pas comme base de données , donc le cycle de vie de la clé ne doit pas être trop long.
Par conséquent, il est généralement recommandé d'utiliser votre clé pour définir le délai d'expiration .

Si un grand nombre de clés expire à un certain moment, Redis peut être bloqué ou même mettre en cache une avalanche à son expiration. Par conséquent, en général, le délai d'expiration des clés pour différentes entreprises doit être dispersé. Parfois, pour la même entreprise, vous pouvez également ajouter une valeur aléatoire au temps pour étaler le délai d'expiration.

1.4. Il est recommandé d’utiliser des opérations par lots pour améliorer l’efficacité

Lorsque nous écrivons quotidiennement du SQL, nous savons tous que les opérations par lots seront plus efficaces. Mettre à jour 50 éléments à la fois est plus efficace que de boucler 50 fois et de mettre à jour un élément à chaque fois. En fait, les commandes d'opération Redis sont également les mêmes.

Une commande exécutée par le client Redis peut être divisée en 4 processus: 1. Envoyer la commande -> 2. Mise en file d'attente des commandes -> 3. Exécution de la commande -> 4. Renvoyer le résultat. 1 et 4 sont appelés RRT (temps d'aller-retour d'exécution de la commande). Redis fournit des commandes d'opération par lots, telles que mget, mset, etc., qui peuvent effectivement sauver RRT. Cependant, la plupart des commandes ne prennent pas en charge les opérations par lots, telles que hgetall, et mhgetall n'existe pas. Pipeline peut résoudre ce problème.

Qu'est-ce que Pipeline? Il peut assembler un ensemble de commandes Redis, les transmettre à Redis via un RTT, puis renvoyer les résultats d'exécution de cet ensemble de commandes Redis au client dans l'ordre.

Jetons d'abord un coup d'œil au modèle qui a exécuté n commandes sans utiliser Pipeline:

En utilisant Pipeline pour exécuter n commandes, l'ensemble du processus nécessite 1 RTT, le modèle est le suivant:

2. Les commandes que Redis a des pièges

2.1. Attention `O(n)`complexité de la commande, par exemple `hgetall`, `smember`, `lrange`etc.

Parce que Redis exécute les commandes dans un seul thread. La complexité temporelle des commandes telles que hgetall et smember est O (n). Lorsque n continue d'augmenter, le processeur Redis continuera à monter en flèche et à bloquer l'exécution d'autres commandes.

Les commandes telles que hgetall, smember et lrange ne sont pas nécessairement indisponibles. Il est nécessaire d'évaluer globalement la quantité de données, de clarifier la valeur de n, puis de décider. Par exemple, hgetall, s'il y a plus d'éléments de hachage n, hscan peut être utilisé en premier .

2.2 Utilisez la commande moniteur de Redis avec prudence

La commande Redis Monitor est utilisée pour imprimer les commandes reçues par le serveur Redis en temps réel. Si nous voulons savoir quelles opérations de commande le client a effectuées sur le serveur Redis, nous pouvons utiliser la commande Monitor pour l'afficher, mais c'est généralement utilisé pour le débogage . Essayez de ne pas l'utiliser en production. use! Parce que la commande monitor peut provoquer une augmentation continue de la mémoire de Redis.

Le modèle de moniteur est Jiangzi. Il affichera toutes les commandes exécutées sur le serveur Redis. De manière générale, le QPS du serveur Redis est très élevé, c'est-à-dire que si la commande de surveillance est exécutée, le serveur Redis est dans le tampon de sortie de le client Monitor. Il y aura beaucoup d '"inventaire", qui occupera beaucoup de mémoire Redis.

2.3. La commande par touches ne peut pas être utilisée dans l'environnement de production

La commande Redis Keys est utilisée pour trouver toutes les clés qui correspondent à un modèle donné. Si vous souhaitez vérifier le nombre de clés d'un certain type dans Redis, de nombreux amis pensent à utiliser la commande de touches, comme suit:

keys key前缀*
复制代码

Cependant, redis keystraverse la correspondance, et la complexité est O（n）que plus il y a de données dans la base de données, plus il est lent. Nous savons que redis est monothread. S'il y a beaucoup de données, l'instruction keys provoquera le blocage du thread redis, et le service en ligne se mettra également en pause. Le service ne reprendra pas tant que l'instruction ne sera pas exécutée. Par conséquent, généralement dans un environnement de production, n'utilisez pas la commande keys . Le document officiel indique également:

Attention: considérez KEYS comme une commande qui ne doit être utilisée qu'avec un soin extrême dans les environnements de production. Cela peut ruiner les performances lorsqu'il est exécuté sur des bases de données volumineuses. Cette commande est destinée au débogage et aux opérations spéciales, telles que la modification de la disposition de votre espace de clés. N'utilisez pas KEYS dans votre code d'application habituel. Si vous recherchez un moyen de trouver des clés dans un sous-ensemble de votre espace de clés, envisagez d'utiliser des ensembles.

En fait, vous pouvez utiliser la commande scan, qui fournit des fonctions de correspondance de modèle comme la commande de touches. Sa complexité est également O (n), mais elle est effectuée étape par étape à travers le curseur, et ne bloquera pas le thread redis ; mais il y aura une certaine probabilité de répétition , et il doit être dédupliqué une fois sur le client .

scan prend en charge les commandes itératives incrémentielles, et les commandes itératives incrémentielles présentent également des inconvénients: par exemple, l'utilisation de la commande SMEMBERS peut renvoyer tous les éléments actuellement contenus dans la clé définie, mais pour les commandes itératives incrémentielles telles que SCAN, car lors de l'itération incrémentielle des touches , les clés peuvent être modifiées, de sorte que la commande d'itération incrémentielle ne peut fournir que des garanties limitées pour les éléments renvoyés.

2.4 Interdire l'utilisation de fluxhall, flushdb

La commande Flushall est utilisée pour effacer les données de l'ensemble du serveur Redis (supprimer toutes les clés de toutes les bases de données).

La commande Flushdb est utilisée pour effacer toutes les clés de la base de données actuelle.

Ces deux commandes sont atomiques et ne mettront pas fin à l'exécution. Une fois que l'exécution démarre, l'exécution n'échouera pas.

2.5 Faites attention à l'utilisation de la commande del

Quelle commande utilisez-vous généralement pour supprimer une clé? Est-ce une suppression directe? Si vous supprimez une clé, vous pouvez utiliser directement la commande del. Mais avez-vous pensé à la complexité temporelle de del? Discutons-en par situation:

Si vous supprimez une clé de type String, la complexité temporelle est O（1）, vous pouvez directement supprimer .
Si vous supprimez un type List / Hash / Set / ZSet, sa complexité est O(n), n représente le nombre d'éléments.

Par conséquent, si vous supprimez une clé List / Hash / Set / ZSet, plus il y a d'éléments, plus il est lent. Lorsque n est très grand, portez une attention particulière à celui - ci , ce qui bloquera le thread principal. Donc, si del n'est pas utilisé, comment devrions-nous le supprimer?

S'il s'agit d'un type List, vous pouvez l'exécuter lpop或者rpopjusqu'à ce que tous les éléments soient supprimés.

S'il est de type Hash / Set / ZSet, vous pouvez d'abord exécuter la hscan/sscan/scanrequête, puis exécuter pour hdel/srem/zremsupprimer chaque élément à son tour.

2.6 Évitez d'utiliser SORT, SINTER et d'autres commandes très complexes.

L'exécution de commandes plus complexes consommera plus de ressources CPU et bloquera le thread principal. Vous devez donc éviter d'exécuter de telles SORT、SINTER、SINTERSTORE、ZUNIONSTORE、ZINTERSTOREcommandes d'agrégation, il est généralement recommandé de le placer côté client pour exécution.

3. Projeter l'opération de combat et d'évitement de puits

3.1 Points à noter lors de l'utilisation de verrous distribués

Le verrou distribué est en fait la réalisation d'un verrou qui contrôle différents processus d'un système distribué pour accéder ensemble aux ressources partagées. Les verrous distribués sont nécessaires pour les scénarios commerciaux tels que la passation de commandes avec des pointes et la saisie d'enveloppes rouges. Nous utilisons souvent Redis comme un verrou distribué, principalement avec ces points d'attention:

3.1.1 Les deux commandes SETNX + EXPIRE sont écrites séparément (un exemple typique d'implémentation d'erreur)

if（jedis.setnx(key_resource_id,lock_value) == 1）{ //加锁
    expire（key_resource_id，100）; //设置过期时间
    try {
        do something  //业务请求
    }catch(){
　　}
　　finally {
       jedis.del(key_resource_id); //释放锁
    }
}
复制代码

Si le setnxverrou est exécuté et que le délai d'expiration est sur le point d'être exécuté, le processus se bloque ou doit être redémarré pour maintenance, alors le verrou sera "immortel" et les autres threads ne pourront jamais obtenir le verrou , de sorte que le général le verrou distribué ne peut pas être comme cela.

3.1.2 La valeur de la valeur SETNX + est le temps d'expiration (certains petits partenaires implémentent de cette façon, il y a des fosses)

long expires = System.currentTimeMillis() + expireTime; //系统时间+设置的过期时间
String expiresStr = String.valueOf(expires);

// 如果当前锁不存在，返回加锁成功
if (jedis.setnx(key_resource_id, expiresStr) == 1) {
        return true;
} 
// 如果锁已经存在，获取锁的过期时间
String currentValueStr = jedis.get(key_resource_id);

// 如果获取到的过期时间，小于系统当前时间，表示已经过期
if (currentValueStr != null && Long.parseLong(currentValueStr) < System.currentTimeMillis()) {

     // 锁已过期，获取上一个锁的过期时间，并设置现在锁的过期时间（不了解redis的getSet命令的小伙伴，可以去官网看下哈）
    String oldValueStr = jedis.getSet(key_resource_id, expiresStr);
    
    if (oldValueStr != null && oldValueStr.equals(currentValueStr)) {
         // 考虑多线程并发的情况，只有一个线程的设置值和当前值相同，它才可以加锁
         return true;
    }
}
        
//其他情况，均返回加锁失败
return false;
}
复制代码

Inconvénients de ce schéma :

L'heure d'expiration est générée par le client lui-même. Dans un environnement distribué, l'heure de chaque client doit être synchronisée

Il n'y a pas d'identification unique du titulaire, et il peut être libéré / déverrouillé par d'autres clients.

Lorsque le verrou expire, plusieurs clients simultanés les demandent en même temps et ils sont tous exécutés jedis.getSet(). En fin de compte, un seul client peut verrouiller le verrou avec succès, mais l'heure d'expiration du verrou client peut être écrasée par d'autres clients.

3.1.3: Commande étendue SET (SET EX PX NX) (faites attention aux problèmes éventuels)

if（jedis.set(key_resource_id, lock_value, "NX", "EX", 100s) == 1）{ //加锁
    try {
        do something  //业务处理
    }catch(){
　　}
　　finally {
       jedis.del(key_resource_id); //释放锁
    }
}
复制代码

Il peut encore y avoir des problèmes avec cette solution:

Le verrou a expiré et est libéré, et l'entreprise n'a pas encore été exécutée.
Le verrou a été supprimé par erreur par un autre thread.

3.1.4 SET EX PX NX + vérifie la valeur aléatoire unique et la supprime à nouveau (le problème de la suppression accidentelle est résolu, il y a toujours le problème du verrou expiré et l'entreprise n'est pas exécutée)

if（jedis.set(key_resource_id, uni_request_id, "NX", "EX", 100s) == 1）{ //加锁
    try {
        do something  //业务处理
    }catch(){
　　}
　　finally {
       //判断是不是当前线程加的锁,是才释放
       if (uni_request_id.equals(jedis.get(key_resource_id))) {
        jedis.del(lockKey); //释放锁
        }
    }
}
复制代码

Ici, juger si le verrou ajouté et libéré par le thread actuel n'est pas une opération atomique. Si vous appelez jedis.del () pour libérer le verrou, le verrou n'appartiendra peut-être plus au client actuel et le verrou ajouté par d'autres sera libéré.

Utilisez généralement le script lua à la place. Le script lua est le suivant:

if redis.call('get',KEYS[1]) == ARGV[1] then 
   return redis.call('del',KEYS[1]) 
else
   return 0
end;
复制代码

3.1.5 Le framework Redisson + l'algorithme Redlock résout le problème de la libération expirée du verrou, de l'exécution incomplète de l'entreprise + problème autonome

Redisson utilise une Watch dogsolution pour résoudre le problème de l'expiration et de la libération des verrous, et l'entreprise n'est pas exécutée. Le diagramme schématique de Redisson est le suivant:

Les verrous distribués ci-dessus ont toujours des problèmes autonomes:

Si le thread un obtient le verrou sur le nœud maître Redis, mais que la clé verrouillée n'a pas été synchronisée avec le nœud esclave. À ce moment précis, lorsque le nœud maître échoue, un nœud esclave sera mis à niveau vers un nœud maître. Le thread deux peut acquérir le verrou de la même clé, mais le thread un a déjà acquis le verrou et la sécurité du verrou est perdue.

Pour les problèmes autonomes, l'algorithme Redlock peut être utilisé. Les amis intéressés peuvent lire mon article, sept solutions! Discutez de la posture d'utilisation correcte du verrou distribué Redis

3.2 Précautions pour la cohérence du cache

S'il s'agit d'une demande de lecture, lisez d'abord le cache, puis lisez la base de données
En cas de demande d'écriture, mettez d'abord à jour la base de données, puis écrivez dans le cache
Chaque fois que vous mettez à jour les données, vous devez vider le cache
Le cache doit généralement définir une certaine invalidation d'expiration
Si les exigences de cohérence sont élevées, biglog + MQ peut être utilisé pour garantir.

Les amis intéressés peuvent lire mon article: Dans un environnement concurrent, devez-vous d'abord utiliser la base de données ou le cache?

3.3 Évaluer correctement la capacité Redis pour éviter l'invalidation du délai d'expiration précédemment défini en raison de la fréquence de couverture définie.

Nous savons que tous les types de structure de données de Redis peuvent définir le délai d'expiration. Supposons qu'une chaîne ait une heure d'expiration définie et que si vous la réinitialisez, l'heure d'expiration précédente sera invalide.

Le setKeycode source de Redis est le suivant:

void setKey(redisDb *db,robj *key,robj *val) {
    if(lookupKeyWrite(db,key)==NULL) {
       dbAdd(db,key,val);
    }else{
    dbOverwrite(db,key,val);
    }
    incrRefCount(val);
    removeExpire(db,key); //去掉过期时间
    signalModifiedKey(db,key);
}
复制代码

Dans le développement commercial réel, en même temps, nous devons évaluer raisonnablement la capacité de Redis pour éviter une couverture fréquente, ce qui rendra invalide la clé avec le délai d'expiration. Le novice Xiaobai est facile de faire cette erreur.

3.4 Problème de pénétration du cache

Examinons d'abord une méthode d'utilisation du cache commune: lorsqu'une demande de lecture arrive, vérifiez d'abord le cache, et si le cache a une valeur atteinte, il retournera directement; si le cache manque, il vérifiera la base de données, puis mettra à jour la valeur de la base de données dans le cache, puis retournez.

Pénétration du cache : fait référence à l'interrogation de certaines données inexistantes, car le cache est manqué, il doit être interrogé à partir de la base de données et les données ne sont pas trouvées, elles ne seront pas écrites dans le cache, ce qui entraînera la non- données existantes pour accéder à la base de données à chaque fois qu'une requête est effectuée. Requête, puis exercez une pression sur la base de données.

En termes simples, lorsqu'une demande de lecture est accédée, ni le cache ni la base de données n'ont une certaine valeur, ce qui entraînera chaque requête de requête pour cette valeur à pénétrer dans la base de données, qui est la pénétration du cache.

La pénétration du cache est généralement causée par ces situations:

Conception d'entreprise déraisonnable , par exemple, la plupart des utilisateurs n'ont pas de protecteurs, mais chaque demande de votre part est mise en cache et vous pouvez demander si un certain userid est protégé.
Des erreurs dans les affaires / opérations / développement , telles que les données de cache et de base de données, ont été supprimées par erreur .
Les pirates informatiques demandent des attaques illégales , comme des pirates qui fabriquent délibérément un grand nombre de demandes illégales pour lire des données commerciales inexistantes.

Comment éviter la pénétration du cache? Il existe généralement trois méthodes.

1. S'il s'agit d'une demande illégale, nous vérifions les paramètres à l'entrée de l'API pour filtrer les valeurs illégales.
1. Si la base de données de requête est vide, nous pouvons définir une valeur nulle ou une valeur par défaut pour le cache. Mais si une demande d'écriture arrive, le cache doit être mis à jour pour assurer la cohérence du cache, et en même temps, définir une heure d'expiration appropriée pour le cache à la fin. (Couramment utilisé en entreprise, simple et efficace)
1. Utilisez des filtres de floraison pour déterminer rapidement si des données existent. Autrement dit, lorsqu'une demande de requête arrive, le filtre de floraison est utilisé pour déterminer si la valeur existe, puis la requête se poursuit.

Principe du filtre Bloom: Il se compose d'un tableau bitmap avec une valeur initiale de 0 et N fonctions de hachage. On exécute N algorithmes de hachage sur une clé pour obtenir N valeurs, et définit ces N valeurs à 1 après le hachage dans le tableau de bits, puis lors de la vérification, si ces positions spécifiques sont toutes à 1, alors filtrage de floraison Le dispositif détermine que le la clé existe.

3.5 Problème de Cache Snow Ben

Caching Xueben: fait référence à la grande quantité de données dans le cache jusqu'à l'heure d'expiration, et la quantité de données de requête est énorme, et toutes les demandes accèdent directement à la base de données, provoquant une pression excessive sur la base de données ou même des temps d'arrêt.

La mise en cache de Xueben est généralement causée par une grande quantité de données expirant en même temps. Pour cette raison, il peut être résolu en réglant le délai d'expiration de manière uniforme, c'est-à-dire en rendant le délai d'expiration relativement discret. Si vous utilisez une valeur fixe plus grande + une valeur aléatoire plus petite, 5 heures + 0 à 1800 secondes sauce violette.
Les échecs et les temps d'arrêt de Redis peuvent également entraîner la neige du cache. Cela nécessite la construction d'un cluster à haute disponibilité Redis.

3.6 Problème de panne du cache

Répartition du cache: fait référence au moment où la touche de raccourci expire à un certain moment dans le temps, et un grand nombre de demandes simultanées pour cette clé arrivent à ce moment-là, et un grand nombre de demandes atteignent la base de données.

La ventilation du cache ressemble un peu à, en fait, la différence entre les deux est que le cache Xueben signifie que la base de données est trop sous pression ou même que la machine est en panne. La ventilation du cache est juste un grand nombre de requêtes simultanées à la base de données DB niveau. On peut considérer que la ventilation est un sous-ensemble du cache Xueben. Certains articles pensent que la différence entre les deux est que la ventilation est pour un cache de touches de raccourci, tandis que Xueben a de nombreuses clés.

Il existe deux solutions:

1. Utilisez le schéma de verrouillage mutex . Lorsque le cache échoue, au lieu de charger immédiatement les données de la base de données, utilisez d'abord certaines commandes d'opération atomique avec un retour réussi, telles que (Redis setnx) pour fonctionner, puis chargez les données de la base de données de base de données et définissez le cache en cas de succès. Sinon, essayez de récupérer le cache.
2. «Ne jamais expirer» signifie que lorsque le délai d'expiration n'est pas défini, mais que les données actives sont sur le point d'expirer, le thread asynchrone se met à jour et définit le délai d'expiration.

3.7. Problème de raccourci clavier de cache

Dans Redis, nous appelons les touches avec une fréquence d'accès élevée comme des touches de hotspot. Si une demande de raccourci clavier est envoyée à l'hôte du serveur, en raison du nombre extrêmement important de demandes, l'hôte peut être insuffisant en ressources ou même en temps d'arrêt, affectant ainsi les services normaux.

Et comment le raccourci clavier est-il généré? Il y a deux principales raisons:

Les données consommées par les utilisateurs sont beaucoup plus volumineuses que les données produites, telles que les pics, les actualités à chaud et d'autres scénarios où lire de plus en moins écrire.

La fragmentation des demandes est concentrée, ce qui dépasse les performances d'un seul serveur Redi. Par exemple, avec une clé de nom fixe et un hachage tombant sur le même serveur, le trafic instantané est extrêmement important, dépassant le goulot d'étranglement de la machine et provoquant des problèmes de raccourcis clavier.

Alors dans le développement quotidien, comment identifier le raccourci clavier?

Jugez qui sont des raccourcis clavier basés sur l'expérience;

Rapport sur les statistiques des clients;

Rapports sur la couche d'agent de service

Comment résoudre le problème des touches de raccourci?

Extension du cluster Redis: augmentez les copies de partition pour équilibrer le trafic de lecture;

Hash la touche de raccourci, comme la sauvegarde d'une clé comme key1, key2 ... keyN, N sauvegardes des mêmes données, N sauvegardes distribuées vers différents fragments et un accès aléatoire à l'une des N sauvegardes pendant l'accès. circulation;

Utilisez le cache de deuxième niveau, le cache local JVM, pour réduire les demandes de lecture Redis.

4. Fonctionnement et maintenance de la configuration Redis

4.1 Utilisez des connexions longues au lieu de connexions courtes et configurez correctement le pool de connexions du client

Si vous utilisez une connexion courte, vous devez passer par la poignée de main TCP à trois et quatre mains agitées à chaque fois, ce qui prendra du temps. Cependant, pour une longue connexion, il établit une connexion une fois, et les commandes redis peuvent être utilisées tout le temps. Jiangzi peut réduire le temps pour établir une connexion redis.
Le pool de connexions peut établir plusieurs connexions sur le client sans les libérer. Lorsqu'une connexion est nécessaire, il n'est pas nécessaire de créer une connexion à chaque fois, ce qui permet de gagner du temps. Mais vous devez définir les paramètres de manière raisonnable et vous devez libérer les ressources de connexion à temps lorsque vous n'utilisez pas Redis pendant une longue période.

4.2 N'utiliser que db0

L'architecture autonome de Redis interdit l'utilisation de non-db0. Il y a deux raisons

Pour une connexion, Redis exécute la commande select 0 et sélectionnez 1 pour basculer, ce qui consommera une nouvelle énergie.
Redis Cluster ne prend en charge que db0, si vous souhaitez migrer, le coût est élevé

4.3 Définir la stratégie d'élimination maxmemory + appropriée.

Afin d'éviter que le retard de mémoire ne gonfle. Par exemple, parfois, le volume d'affaires a augmenté, la clé redis est beaucoup utilisée, la mémoire est directement insuffisante et le frère d'exploitation et de maintenance a également oublié d'augmenter la mémoire. Redis raccroche-t-il comme ça? Par conséquent, il est nécessaire de sélectionner la stratégie maxmemory (stratégie d'élimination maximale de la mémoire) et de définir le délai d'expiration en fonction de l'activité réelle. Il existe au total 8 stratégies d'élimination de la mémoire:

Volatile-lru: Lorsque la mémoire est insuffisante pour accueillir les données nouvellement écrites, l'algorithme LRU (le moins récemment utilisé) est utilisé pour éliminer la clé avec le temps d'expiration;
allkeys-lru: Lorsque la mémoire est insuffisante pour accueillir les données nouvellement écrites, l'algorithme LRU (utilisé le moins récemment) est utilisé pour éliminer toutes les clés.
Volatile-lfu: Nouveau dans la version 4.0. Lorsque la mémoire est insuffisante pour accueillir les données nouvellement écrites, l'algorithme LFU est utilisé pour supprimer la clé de la clé expirée.
allkeys-lfu: Nouveau dans la version 4.0, lorsque la mémoire n'est pas suffisante pour accueillir les données nouvellement écrites, l'algorithme LFU est utilisé pour éliminer toutes les clés;
Volatile-aléatoire: lorsque la mémoire n'est pas suffisante pour contenir les données nouvellement écrites, les données sont éliminées aléatoirement de la clé avec le délai d'expiration défini.
allkeys-random: lorsque la mémoire est insuffisante pour accueillir les données nouvellement écrites, les données sont éliminées aléatoirement de toutes les clés.
Volatile-ttl: Lorsque la mémoire n'est pas suffisante pour accueillir les données nouvellement écrites, parmi les clés avec l'heure d'expiration définie, la clé sera éliminée en fonction de l'heure d'expiration, et la première expirée sera éliminée en premier;
noeviction: La stratégie par défaut, lorsque la mémoire n'est pas suffisante pour accueillir les données nouvellement écrites, la nouvelle opération d'écriture signalera une erreur.

4.4 Activer le mécanisme sans paresseux

La version Redis4.0 + prend en charge le mécanisme sans paresseux. Si votre Redis a toujours bigKey, il est recommandé d'activer sans paresseux. Lorsqu'il est activé, si Redis supprime un bigkey, l'opération fastidieuse de libération de mémoire sera exécutée dans le thread d'arrière-plan, réduisant ainsi l'impact de blocage sur le thread principal.

Auteur:
lien de cueillette d'un escargot : https: //juejin.cn/post/6942643266613411854
Source: Nuggets