Cet article partagera avec vous quelques questions d'entretien Redis à haute fréquence. Il a une certaine valeur de référence. Les amis dans le besoin peuvent s'y référer. J'espère qu'il sera utile à tout le monde.
Qu'est-ce que Redis
Redis (Remote Dictionary Server) est un open source (Remote Dictionary Server) écrit en Base de données clé-valeur non relationnelle (NoSQL) hautes performances sous licence BSD (langage C).
Redis peut stocker des mappages entre les clés et cinq types de valeurs différents. Le type de clé ne peut être qu'une chaîne et la valeur prend en charge cinq types de données : chaîne, liste, ensemble, table de hachage et ensemble ordonné.
Contrairement aux bases de données traditionnelles, les données Redis sont stockées en mémoire, la vitesse de lecture et d'écriture est donc très rapide. Par conséquent, Redis est largement utilisé dans le sens du cache et peut gérer plus de 100 000 opérations de lecture et d'écriture par seconde. . La base de données clé-valeur la plus rapide connue. De plus, Redis est également souvent utilisé pour les verrous distribués. De plus, Redis prend en charge les transactions, la persistance, les scripts LUA, les événements pilotés par LRU et diverses solutions de cluster.
Quels sont les avantages et les inconvénients de Redis
Avantages
Excellentes performances de lecture et d'écriture , Redis peut lire La vitesse d'écriture est de 110 000 fois/s et la vitesse d'écriture est de 81 000 fois/s.
Prend en charge la persistance des données et prend en charge deux méthodes de persistance : AOF et RDB.
Prend en charge les transactions. Toutes les opérations de Redis sont atomiques. En même temps, Redis prend également en charge l'exécution atomique après la fusion de plusieurs opérations.
Structures de données riches, en plus de prendre en charge la valeur de type chaîne, il prend également en charge les structures de hachage, set, zset, list et autres.
Prend en charge la réplication maître-esclave. L'hôte synchronisera automatiquement les données avec l'esclave, permettant la séparation en lecture et en écriture.
Inconvénients
La capacité de la base de données est limitée par la mémoire physique et ne peut pas être utilisée pour une lecture et une écriture hautes performances de données massives. Par conséquent, les scénarios adaptés à Redis sont les suivants. principalement limité à de petites quantités de données. Opérations et calculs hautes performances.
Redis n'a pas de fonctions automatiques de tolérance aux pannes et de récupération. Le temps d'arrêt des machines hôtes et esclaves entraînera l'échec de certaines requêtes de lecture et d'écriture frontales. Vous devez attendre que la machine redémarre. ou changez manuellement l’adresse IP frontale pour récupérer.
La machine hôte est en panne. Certaines données n'ont pas pu être synchronisées avec la machine esclave à temps avant que la machine ne tombe en panne. Après le changement d'IP, une incohérence des données sera introduite, ce qui réduit la disponibilité du système.
Redis est difficile à prendre en charge l'expansion en ligne. Lorsque la capacité du cluster atteint la limite supérieure, l'expansion en ligne deviendra très compliquée. Afin d'éviter ce problème, le personnel d'exploitation et de maintenance doit s'assurer qu'il y a suffisamment d'espace lorsque le système est mis en ligne, ce qui entraîne un gaspillage important de ressources.
Pourquoi utiliser le cache, pourquoi utiliser Redis
Principalement à partir des deux points "haute performance" et "haute concurrence" Voyons regardez ce problème.
Hautes performances :
Si l'utilisateur accède à certaines données de la base de données pour la première fois. Ce processus sera plus lent car il est lu à partir du disque dur. Stockez les données consultées par l'utilisateur dans le cache, de sorte que lors du prochain accès aux données, elles puissent être obtenues directement à partir du cache. Faire fonctionner le cache consiste à faire fonctionner directement la mémoire, la vitesse est donc assez rapide. Si les données correspondantes dans la base de données changent, modifiez simplement les données correspondantes dans le cache de manière synchrone !
Concurrence élevée :
Les requêtes auxquelles le cache d'opération directe peut résister sont bien plus importantes que l'accès direct à la base de données, on peut donc envisager de transférer une partie des données de la base de données vers le cache, afin qu'une partie des requêtes de l'utilisateur aille directement dans le cache sans passer par la base de données.
Pourquoi utiliser Redis au lieu de map/guava pour la mise en cache ?
Le cache est divisé en cache local et cache distribué cache. En prenant Java comme exemple, la mise en cache locale est implémentée à l'aide de la carte intégrée ou de la goyave. Les principales fonctionnalités sont légères et rapides. Le cycle de vie se termine par la destruction de la machine virtuelle Java et, dans le cas de plusieurs instances, de chaque cache. doit être sauvegardé et le cache n'est pas cohérent.
L'utilisation de redis ou memcached est appelée cache distribué. Dans le cas de plusieurs instances, chaque instance partage un cache de données, et le cache est cohérent. L'inconvénient est que le service Redis ou Memcached doit rester hautement disponible et que l'ensemble de l'architecture du programme est relativement complexe.
Pourquoi Redis est-il si rapide
1 Entièrement basé sur la mémoire, la plupart des requêtes sont de pures opérations de mémoire, très rapides. Les données sont stockées en mémoire, comme HashMap. L'avantage de HashMap est que la complexité temporelle de la recherche et de l'opération est O(1)
2. est également simple.Dans Redis La structure des données est spécialement conçue ;
3. L'utilisation d'un seul thread évite les changements de contexte inutiles et les conditions de concurrence, et il n'est pas nécessaire d'envisager le changement causé par le multi-processus ou le multi-threading. pour consommer le CPU. Divers problèmes de verrouillage, il n'y a pas d'opérations de verrouillage et de libération, et il n'y a pas de consommation de performances causée par d'éventuels blocages
;
4. Utilisez un modèle de multiplexage d'E/S multicanal, IO non bloquant ;
5. Utilisez différents modèles sous-jacents, les méthodes de mise en œuvre sous-jacentes et les protocoles d'application pour la communication avec le client sont différents. Redis a directement construit son propre mécanisme de VM, car si le système général appelle les fonctions système, il perdra un certain temps à se déplacer et à demander
Quels types de données possède Redis ?
Redis dispose principalement de 5 types de données, dont String, List, Set, Zset et Hash, qui répondent à la plupart des exigences d'utilisation
Type
Valeur de stockage
类型
|
存储值
|
操作
|
应用场景
|
STRING
|
字符串、整数或者浮点数 |
对整个字符串或者字符串的其中一部分执行操作；
对整数和浮点数执行自增或者自减操作 |
做简单的键值对缓存 |
LIST
|
列表 |
从两端压入或者弹出元素；
对单个或者多个元素进行修剪，只保留一个范围内的元素 |
存储一些列表型的数据结构，类似粉丝列表、文章的评论列表之类的数据 |
SET
|
无序集合
|
添加、获取、移除单个元素；
检查一个元素是否存在于集合中；
计算交集、并集、差集；
从集合里面随机获取元素 |
交集、并集、差集的操作，比如交集，可以把两个人的粉丝列表整一个交集 |
HASH
|
哈希
|
添加、获取、移除单个键值对；
获取所有键值对；
检查某个键是否存在 |
结构化的数据，比如一个对象 |
| ZSET |
有序集合
|
添加、获取、删除元素；
根据分值范围或者成员来获取元素；
计算一个键的排名 |
去重但可以排序，如获取排名前几名的用户 |
|
Fonctionnement |
Scénario d'application |
| STRING |
Chaîne, nombre entier ou nombre à virgule flottante |
Pour la chaîne entière ou une partie de la chaîne Effectuer des opérations ; Effectuer des opérations d'incrémentation ou de décrémentation sur des entiers et des nombres à virgule flottante |
Effectuer une mise en cache simple de paires clé-valeur |
LIST| Liste |
Poussez ou faites apparaître des éléments des deux extrémités Pour un seul ou un ; Coupez plusieurs éléments et ne conservez que les éléments compris dans une plage |
Stockage de certaines structures de données de type liste, similaires aux listes de fans, aux listes de commentaires d'articles et à d'autres données |
SET |
Ensemble non ordonné |
Ajouter, obtenir et supprimer un seul element; Vérifiez si un élément existe dans l'ensemble; Calculez l'intersection, l'union et la différence Obtenez aléatoirement les éléments de l'ensemble |
Intersection, union, et les opérations de différence, telles que l'intersection, peuvent combiner les listes de fans de deux personnes en une seule intersection |
| HASH td> |
Hash |
Ajouter, obtenir, supprimer une seule paire clé-valeur Obtenir toutes les paires clé-valeur Vérifier si une clé existe ; |
Données structurées, telles qu'un objet |
| ZSET | Ensemble ordonné |
Ajouter, obtenir, supprimer des éléments Obtenir des éléments en fonction de la plage de scores ou des membres Calculer le classement d'une clé | Déduplication mais peut être triée, par exemple en obtenant les principaux utilisateurs |
Scénarios d'application Redis
Résumé 1
1. Vous pouvez effectuer des opérations d'incrémentation et de décrémentation sur String pour réaliser la fonction de compteur. Redis, une base de données en mémoire, offre des performances de lecture et d'écriture très élevées et est très adaptée au stockage du nombre de lectures et d'écritures fréquentes.
2. Cache
Mettez les données chaudes en mémoire, définissez l'utilisation maximale de la mémoire et la stratégie d'élimination pour garantir le taux de réussite du cache.
3. Cache de session
Vous pouvez utiliser Redis pour stocker uniformément les informations de session de plusieurs serveurs d'applications. Lorsque le serveur d'applications ne stocke plus les informations de session de l'utilisateur, il n'a plus d'état. Un utilisateur peut demander n'importe quel serveur d'applications, ce qui facilite l'obtention d'une haute disponibilité et d'une évolutivité.
4. Cache pleine page (FPC)
En plus des jetons de session de base, Redis fournit également une plateforme FPC très simple. En prenant Magento comme exemple, Magento fournit un plugin pour utiliser Redis comme backend de cache pleine page. De plus, pour les utilisateurs de WordPress, Pantheon dispose d’un très bon plug-in wp-redis, qui pourra vous aider à charger le plus rapidement possible les pages que vous avez parcourues.
5. Table de recherche
Par exemple, les enregistrements DNS sont très adaptés au stockage à l'aide de Redis. La table de recherche est similaire au cache et profite également de la fonctionnalité de recherche rapide de Redis. Mais le contenu de la table de recherche ne peut pas être invalidé, alors que le contenu du cache peut être invalidé, car le cache ne sert pas de source de données fiable.
6. File d'attente des messages (fonction de publication/abonnement)
La liste est une liste doublement liée qui peut écrire et lire des messages via lpush et rpop. Cependant, il est préférable d’utiliser des middlewares de messagerie tels que Kafka et RabbitMQ.
7. Implémentation de verrous distribués
Dans un scénario distribué, les verrous dans un environnement autonome ne peuvent pas être utilisés pour synchroniser des processus sur plusieurs nœuds. Vous pouvez utiliser la commande SETNX fournie avec Redis pour implémenter des verrous distribués. De plus, vous pouvez également utiliser l'implémentation de verrouillage distribué RedLock officiellement fournie.
8. Autres
Set peut mettre en œuvre des opérations telles que l'intersection et l'union, réalisant ainsi des fonctions telles que des amis communs. ZSet peut implémenter des opérations ordonnées pour réaliser des fonctions telles que des classements.
Résumé 2
Redis a un très gros avantage par rapport aux autres caches, c'est-à-dire qu'il prend en charge plusieurs types de données.
Chaîne de chaîne de description du type de données, le format de hachage de stockage k-v le plus simple, la valeur est un champ et une valeur, adaptée aux scénarios tels que ID-Detail. list est une liste simple, une liste séquentielle, prend en charge l'insertion de données à la première ou à la dernière position, une liste non ordonnée, une vitesse de recherche rapide, adaptée au traitement des intersections, des unions et des différences ensemble trié ensemble ordonné
En fait, via les données ci-dessus Sur la base des caractéristiques du type, vous pouvez essentiellement penser à des scénarios d'application appropriés.
chaîne
- convient au stockage k-v le plus simple, similaire à la structure de stockage Memcached, au code de vérification SMS, aux informations de configuration, etc., utilisez ce type pour stocker.
hash
- Généralement la clé est un identifiant ou un identifiant unique, et la valeur correspond aux détails. Tels que les détails du produit, les informations personnelles, les actualités, etc.
list
- Parce que la liste est ordonnée, elle est plus adaptée au stockage de certaines données ordonnées et relativement fixes. Tels que le tableau des provinces et des villes, le tableau du dictionnaire, etc. Étant donné que la liste est ordonnée, elle peut être triée en fonction du temps d'écriture, comme les dernières actualités, la file d'attente des messages, etc.
ensemble
- peut être simplement compris comme un modèle de liste d'identification, par exemple les amis qu'une personne a sur Weibo. La meilleure chose à propos d'un ensemble est qu'il peut fournir une intersection entre deux ensembles. , opérations d’union et de différence. Par exemple : Trouver des amis communs entre deux personnes, etc.
Ensemble trié
- est une version améliorée de l'ensemble, ajoutant un paramètre de score, qui triera automatiquement en fonction de la valeur du score. Il est plus adapté aux données telles que le top 10 qui ne sont pas triées en fonction du temps d'insertion.
Comme mentionné ci-dessus, bien que Redis ne soit pas une structure de données aussi complexe qu'une base de données relationnelle, il peut convenir à de nombreux scénarios et possède plus de structures de données que les caches généraux. Comprendre les scénarios commerciaux adaptés à chaque structure de données contribuera non seulement à améliorer l'efficacité du développement, mais également à utiliser efficacement les performances de Redis.
Qu'est-ce que la persistance Redis ?
La persistance consiste à écrire les données de mémoire sur le disque pour éviter que les données de mémoire ne soient perdues lorsque le service tombe en panne.
Quel est le mécanisme de persistance de Redis ? Quels sont les avantages et les inconvénients de chacun ?
Redis fournit deux mécanismes de persistance, RDB (par défaut) et AOF
RDB : c'est l'instantané de l'abréviation de Redis DataBase
RDB C'est la méthode de persistance par défaut de Redis. Les données de la mémoire sont enregistrées sur le disque dur sous la forme d'un instantané selon une certaine période de temps, et le fichier de données correspondant est dump.rdb. La période d'instantané est définie via le paramètre save dans le fichier de configuration.
Avantages : 
1 Il n'y a qu'un seul fichier dump.rdb, ce qui est pratique pour la persistance. 2. Bonne tolérance aux catastrophes, un fichier peut être enregistré sur un disque sécurisé.
3. Pour maximiser les performances, forkez le processus enfant pour terminer l'opération d'écriture et permettez au processus principal de continuer à traiter les commandes, afin que les E/S soient maximisées. Utilisez un sous-processus distinct pour la persistance, et le processus principal n'effectuera aucune opération d'E/S, garantissant les hautes performances de Redis.
4. Lorsque l'ensemble de données est volumineux, l'efficacité de démarrage est supérieure à AOF.
Inconvénients :
1. Faible sécurité des données. RDB est conservé à intervalles réguliers. Si Redis échoue entre les persistances, une perte de données se produira. Par conséquent, cette méthode est plus adaptée lorsque les exigences en matière de données ne sont pas strictes)
2. Méthode de persistance AOF (Append-only file) : fait référence à tous les enregistrements de ligne de commande stockés de manière complètement persistante au format de la commande redis. request protocol ) est enregistré sous forme de fichier aof.
AOF : Persistance
La persistance AOF (c'est-à-dire la persistance Append Only File) enregistre chaque commande d'écriture exécutée par Redis dans un fichier journal distinct, lorsque Redis est redémarré, les données du fichier journal persistant seront restaurées.
Lorsque les deux méthodes sont activées en même temps, la récupération de données Redis donnera la priorité à la récupération AOF.
Avantages :
1 La sécurité des données, la persistance peut être configurée avec l'attribut appendfsync, toujours, à chaque opération de commande. est effectué. Enregistrez-le simplement dans le fichier aof une fois.
2. Écrivez des fichiers via le mode ajout. Même si le serveur tombe en panne au milieu, vous pouvez utiliser l'outil redis-check-aof pour résoudre le problème de cohérence des données.
3. Le mode de réécriture du mécanisme AOF. Avant que le fichier AOF ne soit réécrit (les commandes seront fusionnées et réécrites lorsque le fichier est trop volumineux), vous pouvez supprimer certaines commandes (comme flushall par erreur)
Inconvénients :
1. Les fichiers AOF sont plus volumineux que les fichiers RDB et la vitesse de récupération est plus lente.
2. Lorsque l'ensemble de données est volumineux, l'efficacité du démarrage est inférieure à celle de rdb.
Quels sont les avantages et les inconvénients ?
Les fichiers AOF sont mis à jour plus fréquemment que RDB, la priorité est donnée à l'utilisation d'AOF pour restaurer les données
AOF est plus sécurisé et plus grand que RDB
Les performances RDB sont meilleures que AOF
Si les deux sont configurés, AOF est chargé en premier
Comment choisir la méthode de persistance appropriée ?
De manière générale, si vous souhaitez obtenir une sécurité des données comparable à PostgreSQL, vous devez utiliser les deux fonctions de persistance en même temps. Dans ce cas, au redémarrage de Redis, le fichier AOF sera chargé en premier pour restaurer les données d'origine, car dans des circonstances normales, l'ensemble de données enregistré par le fichier AOF est plus complet que l'ensemble de données enregistré par le fichier RDB.
Si vous vous souciez profondément de vos données mais que vous pouvez toujours vous permettre une perte de données en quelques minutes, vous pouvez simplement utiliser la persistance RDB.
De nombreux utilisateurs utilisent uniquement la persistance AOF, mais cette méthode n'est pas recommandée car la génération régulière d'instantanés RDB est très pratique pour la sauvegarde de la base de données, et RDB restaure les ensembles de données plus rapidement que la restauration AOF. De plus, l'utilisation de RDB est plus rapide. peut également éviter les bugs dans les programmes AOF.
Si vous souhaitez que vos données n'existent que lorsque le serveur est en cours d'exécution, vous ne pouvez pas non plus utiliser de méthode de persistance.
Comment étendre les données persistantes et le cache Redis ?
Si Redis est utilisé comme cache, utilisez un hachage cohérent pour obtenir une expansion et une contraction dynamiques.
Si Redis est utilisé comme stockage persistant, une relation de mappage clés-nœuds fixe doit être utilisée et le nombre de nœuds ne peut pas être modifié une fois déterminé. Sinon (c'est-à-dire lorsque les nœuds Redis doivent changer dynamiquement), un système capable de rééquilibrer les données au moment de l'exécution doit être utilisé, et actuellement seul le cluster Redis peut le faire.
Stratégie de suppression des clés d'expiration de Redis
Nous savons tous que Redis est une base de données clé-valeur et nous pouvons définir le délai d'expiration des clés mises en cache dans Rédis. La politique d'expiration de Redis fait référence à la façon dont Redis la gère lorsque la clé mise en cache dans Redis expire.
Les stratégies d'expiration ont généralement les trois types suivants :
Expiration programmée : Chaque clé avec une heure d'expiration doit créer une minuterie, et quand l'heure d'expiration est atteint, il sera effacé immédiatement. Cette stratégie peut immédiatement effacer les données expirées et est très économe en mémoire ; cependant, elle occupera une grande quantité de ressources CPU pour traiter les données expirées, affectant ainsi le temps de réponse et le débit du cache.
Expiration paresseuse : Ce n'est que lors de l'accès à une clé qu'il sera jugé si la clé a expiré, et elle sera effacée si elle expire. Cette stratégie peut économiser au maximum les ressources du processeur, mais elle est très peu respectueuse de la mémoire. Dans des cas extrêmes, un grand nombre de clés expirées ne seront plus accessibles, ne seront donc pas effacées et occuperont une grande quantité de mémoire.
Expiration périodique : A un certain moment, un certain nombre de clés dans le dictionnaire expire d'un certain nombre de bases de données seront analysées et les clés expirées seront effacées. Cette stratégie est un compromis entre les deux premières. En ajustant l'intervalle de temps des analyses planifiées et la consommation de temps limitée de chaque analyse, l'équilibre optimal entre les ressources CPU et mémoire peut être atteint dans différentes circonstances.
(Le dictionnaire expire enregistrera les données de temps d'expiration de toutes les clés avec un délai d'expiration défini, où clé est un pointeur vers une clé dans l'espace clé et valeur est la représentation d'horodatage UNIX de la clé avec une précision en millisecondes. . Le délai d'expiration. L'espace clé fait référence à toutes les clés enregistrées dans le cluster Redis )
Redis utilise à la fois des stratégies d'expiration paresseuse et d'expiration périodique.
Comment définir le délai d'expiration et la validité permanente de la clé Redis ?
Commandes EXPIRE et PERSIST.
Nous savons que le délai d'expiration de la clé est défini via expire, alors comment gérer les données expirées ?
En plus de la politique d'invalidation du cache fourni avec le serveur de cache De plus (Redis propose 6 stratégies par défaut), nous pouvons également effectuer une élimination du cache personnalisée en fonction des besoins spécifiques de l'entreprise :
1. Élimination programmée du cache Nettoyez le cache expiré ;
2. Lorsqu'un utilisateur fait une demande, déterminez si le cache utilisé dans la demande a expiré, accédez au système sous-jacent pour obtenir de nouvelles données et mettre à jour. la cache.
Les deux ont leurs propres avantages et inconvénients. L'inconvénient du premier est qu'il est plus gênant de maintenir un grand nombre de clés en cache. L'inconvénient du second est qu'à chaque fois un utilisateur. le demande, le cache doit être jugé invalide. La logique Relativement compliquée ! La solution à utiliser spécifiquement peut être évaluée en fonction de vos propres scénarios d'application.
Il y a 20 millions de données dans MySQL, mais seulement 200 000 données sont stockées dans redis. Comment s'assurer que les données dans redis sont des données chaudes ?
Lorsque la taille de l'ensemble de données de la mémoire Redis augmente jusqu'à une certaine taille, la stratégie d'élimination des données sera mise en œuvre.
Quelles sont les stratégies d'élimination de la mémoire de Redis ?
La stratégie d'élimination de la mémoire de Redis fait référence à ce qu'il faut faire lorsque la mémoire utilisée pour la mise en cache dans Redis est insuffisant. Traiter les données qui nécessitent une nouvelle écriture et nécessitent de demander de l'espace supplémentaire.
1. Suppression sélective globale de l'espace clé
noeviction : lorsque la mémoire n'est pas suffisante pour accueillir les données nouvellement écrites, nouvelle écriture les opérations signaleront une erreur.
allkeys-lru : Lorsque la mémoire est insuffisante pour accueillir les données nouvellement écrites, dans l'espace clé, supprimez la clé la moins récemment utilisée. (C'est le plus couramment utilisé)
allkeys-random : Lorsque la mémoire n'est pas suffisante pour accueillir les données nouvellement écrites, une clé est supprimée de manière aléatoire de l'espace clé.
2. Suppression sélective de l'espace clé avec délai d'expiration défini
volatile-lru : lorsque la mémoire n'est pas suffisante pour accueillir les données nouvellement écrites , dans l'espace clé avec un délai d'expiration défini, supprimez la clé la moins récemment utilisée.
volatile-random : lorsque la mémoire est insuffisante pour accueillir les données nouvellement écrites, une clé est supprimée de manière aléatoire de l'espace clé avec un délai d'expiration défini.
volatile-ttl : Lorsque la mémoire est insuffisante pour accueillir les données nouvellement écrites, dans l'espace clé avec un délai d'expiration défini, les clés avec un délai d'expiration antérieur seront supprimées en premier.
Résumé
La sélection de la stratégie d'élimination de la mémoire de Redis n'affectera pas le traitement des clés expirées. La stratégie d'élimination de mémoire est utilisée pour gérer les données qui nécessitent de l'espace supplémentaire lorsque la mémoire est insuffisante ; la stratégie d'expiration est utilisée pour gérer les données mises en cache expirées.
Quelles ressources physiques Redis consomme-t-il principalement ?
Mémoire.
Que se passe-t-il lorsque Redis manque de mémoire ?
Si la limite supérieure définie est atteinte, la commande d'écriture Redis renverra un message d'erreur (mais la commande de lecture peut toujours revenir normalement.) Ou vous pouvez configurer le mécanisme d'élimination de mémoire lorsque Redis atteint la limite supérieure de la mémoire. L'ancien contenu sera vidé.
Comment Redis optimise-t-il la mémoire ?
Vous pouvez faire bon usage des données de type collection telles que le hachage, la liste, l'ensemble trié, l'ensemble, etc., car généralement de nombreuses petites valeurs-clés peuvent être stockées ensemble dans un manière plus compacte. Utilisez les hachages autant que possible. Les tables de hachage (ce qui signifie que le nombre stocké dans une table de hachage est petit) utilisent très peu de mémoire, vous devez donc autant que possible résumer votre modèle de données dans une table de hachage. Par exemple, si vous avez un objet utilisateur dans votre système Web, ne définissez pas de clé distincte pour le nom, le prénom, l'adresse e-mail et le mot de passe de l'utilisateur. Stockez plutôt toutes les informations de l'utilisateur dans une table de hachage.
Modèle de thread Redis
Redis a développé un processeur d'événements réseau basé sur le modèle Reactor. Ce processeur est appelé gestionnaire d'événements de fichiers. Sa structure est composée de 4 parties : plusieurs sockets, un multiplexeur IO, un répartiteur d'événements de fichiers et un processeur d'événements. Étant donné que la consommation de la file d'attente du répartiteur d'événements de fichier est monothread, Redis est appelé un modèle monothread.
1. Le gestionnaire d'événements de fichier utilise le programme de multiplexage d'E/S (multiplexage) pour écouter plusieurs sockets en même temps et configurer le socket en fonction de la tâche actuellement effectuée par le socket. gestionnaires d'événements.
2. Lorsque le socket surveillé est prêt à effectuer des opérations telles que réponse de connexion (accepter), lire (lire), écrire (écrire), fermer (fermer), etc., le fichier correspondant à l'opération Événements sera généré et le gestionnaire d'événements de fichier appellera le gestionnaire d'événements précédemment associé au socket pour gérer ces événements.
Bien que le gestionnaire d'événements de fichier s'exécute dans un seul thread, en utilisant un multiplexeur d'E/S pour écouter plusieurs sockets, le gestionnaire d'événements de fichier implémente un modèle de communication réseau haute performance avec lequel il peut également être bien connecté. d'autres modules du serveur Redis qui s'exécutent également de manière monothread, ce qui préserve la simplicité de la conception monothread au sein de Redis.
Qu'est-ce qu'une transaction ?
Une transaction est une opération unique et isolée : toutes les commandes de la transaction sont sérialisées et exécutées dans l'ordre. Lors de l'exécution de la transaction, celle-ci ne sera pas interrompue par les demandes de commandes envoyées par d'autres clients.
Une transaction est une opération atomique : soit toutes les commandes de la transaction sont exécutées, soit aucune d'entre elles n'est exécutée.
Le concept de transaction Redis
L'essence de la transaction Redis est un ensemble de commandes telles que MULTI, EXEC et WATCH. Les transactions prennent en charge l'exécution de plusieurs commandes à la fois, et toutes les commandes d'une transaction seront sérialisées. Pendant le processus d'exécution de la transaction, les commandes dans la file d'attente seront exécutées en série dans l'ordre et les demandes de commandes soumises par d'autres clients ne seront pas insérées dans la séquence de commandes d'exécution de la transaction.
Pour résumer : une transaction Redis est une exécution unique, séquentielle et exclusive d'une série de commandes dans une file d'attente.
Trois étapes de la transaction Redis
1. La transaction démarre MULTI
2. 3. Exécution de la transaction EXEC
Pendant le processus d'exécution de la transaction, si le serveur reçoit une requête autre que EXEC, DISCARD, WATCH et MULTI, il mettra la requête dans la file d'attente
Commandes liées aux transactions RedisLa fonction de transaction Redis est implémentée via les quatre primitives MULTI, EXEC, DISCARD et WATCH
Redis will Toutes les commandes d'une transaction sont sérialisé puis exécuté dans l'ordre.
1.
Redis ne prend pas en charge la restauration
, "Redis n'annule pas lorsqu'une transaction échoue, mais continue d'exécuter les commandes restantes", afin que les composants internes de Redis puissent rester simples et rapides. 2.
Si une erreur se produit dans une commande dans une transaction, alors toutes les commandes ne seront pas exécutées
Si une erreur se produit dans une transaction ; transaction S'il y a une erreur, la commande correcte sera exécutée.
La commande WATCH est un verrou optimiste qui fournit un comportement de vérification et de définition (CAS) pour les transactions Redis. Une ou plusieurs clés peuvent être surveillées. Une fois l'une des clés modifiée (ou supprimée), les transactions suivantes ne seront pas exécutées et la surveillance se poursuit jusqu'à la commande EXEC.
La commande MULTI est utilisée pour démarrer une transaction, et elle renvoie toujours OK. Une fois MULTI exécuté, le client peut continuer à envoyer n'importe quel nombre de commandes au serveur. Ces commandes ne seront pas exécutées immédiatement, mais seront placées dans une file d'attente. Lorsque la commande EXEC est appelée, toutes les commandes de la file d'attente seront exécutées. .
EXEC : exécute des commandes dans tous les blocs de transaction. Renvoie les valeurs de retour de toutes les commandes du bloc de transaction, classées dans l'ordre d'exécution des commandes. Lorsque l'opération est interrompue, la valeur vide nil est renvoyée.
En appelant DISCARD, le client peut vider la file d'attente des transactions et abandonner l'exécution de la transaction, et le client quittera l'état de transaction.
La commande UNWATCH peut annuler la surveillance de toutes les touches par la montre.
Aperçu de la gestion des transactions (ACID)
Atomicité -
Atomicité signifie qu'une transaction est une unité de travail indivisible et que les opérations d'une transaction se produisent toutes ou aucune.
Cohérence -
L'intégrité des données avant et après la transaction doit être cohérente.
Isolement -
Lorsque plusieurs transactions sont exécutées simultanément, l'exécution d'une transaction ne devrait pas affecter l'exécution des autres transactions.
Durabilité -
La durabilité signifie qu'une fois qu'une transaction est validée, ses modifications apportées aux données dans la base de données sont permanentes, alors même si la base de données échoue, cela ne devrait avoir aucun impact sur celui-ci.
Les transactions Redis ont toujours une cohérence et une isolation ACID, et les autres fonctionnalités ne sont pas prises en charge. Les transactions sont également durables lorsque le serveur s'exécute en mode de persistance AOF et que la valeur de l'option appendfsync est toujours.
La transaction Redis prend-elle en charge l'isolement ?
Redis est un programme à processus unique, et il garantit que la transaction ne sera pas interrompue lors de l'exécution de la transaction, et la transaction peut s'exécuter jusqu'à toutes les transactions sont exécutées selon les commandes dans la file d'attente. Par conséquent, les transactions Redis sont toujours isolées.
Les transactions Redis garantissent-elles l'atomicité et prennent-elles en charge la restauration ?
Dans Redis, une seule commande est exécutée de manière atomique, mais les transactions ne le sont pas garanti Atomic et pas de rollback. Si une commande de la transaction ne parvient pas à s'exécuter, les commandes restantes seront quand même exécutées.
Autres implémentations de transactions Redis
Basé sur le script Lua, Redis peut garantir que les commandes du script sont une fois et dans l'ordre. Il est exécuté automatiquement et ne permet pas d'annulation des erreurs d'exécution de transaction. Si certaines commandes ne s'exécutent pas correctement pendant l'exécution, les commandes restantes continueront à s'exécuter.
-
Sur la base de la variable de marque intermédiaire, une autre variable de marque est utilisée pour identifier si la transaction est terminée. Lors de la lecture des données, la variable de marque est d'abord lue pour déterminer si la transaction est terminée. Mais cela nécessitera l’implémentation de code supplémentaire, ce qui est plus fastidieux.
Mode Sentinelle
Introduction à Sentinelle
sentinelle, le nom chinois est sentinelle. Sentinel est un composant très important dans l'organisation du cluster redis. Il a principalement les fonctions suivantes :
Surveillance du cluster : Responsable de surveiller si les processus redis maître et esclave fonctionnent normalement.
Notification de message : Si une instance Redis échoue, la sentinelle est chargée d'envoyer des messages sous forme de notifications d'alarme à l'administrateur.
Failover : Si le nœud maître se bloque, il sera automatiquement transféré vers le nœud esclave.
Centre de configuration : En cas de basculement, informez le client de la nouvelle adresse principale.
Sentinel est utilisé pour atteindre la haute disponibilité du cluster Redis Il est également distribué et fonctionne comme un cluster sentinelle et fonctionne ensemble.
1. Lors du basculement, déterminer si un nœud maître est en panne nécessite le consentement de la plupart des sentinelles, ce qui implique la question de l'élection distribuée.
2. Même si certains nœuds sentinelles raccrochent, le cluster sentinelle peut toujours fonctionner normalement, car si un système de basculement, qui est une partie importante du mécanisme de haute disponibilité, est un point unique, il sera très déroutant.
Connaissance de base de Sentinel
1. Sentinel nécessite au moins 3 instances pour garantir sa robustesse.
2. L'architecture de déploiement maître-esclave Sentinel + redis ne garantit pas zéro perte de données, mais ne peut garantir que la haute disponibilité du cluster redis.
3. Pour l'architecture de déploiement complexe de Sentinel + redis maître-esclave, essayez d'effectuer suffisamment de tests et d'exercices à la fois dans l'environnement de test et dans l'environnement de production.
Solution officielle Redis Cluster (requête de routage côté serveur)
Pouvez-vous expliquer le principe de fonctionnement du mode cluster Redis ? En mode cluster, comment la clé de redis est-elle adressée ? Quels sont les algorithmes d’adressage distribué ? Connaissez-vous l’algorithme de hachage cohérent ?
Introduction
Redis Cluster est une technologie de Sharding côté serveur, officiellement disponible en version 3.0. Redis Cluster n'utilise pas de hachage cohérent, mais utilise le concept de slot, qui est divisé en 16 384 emplacements au total. Envoyez la demande à n'importe quel nœud, et le nœud qui reçoit la demande enverra la demande de requête au nœud correct pour exécution
Description du programme
Par hachage , les données sont fragmentées et chaque nœud stocke uniformément les données dans une certaine plage d'emplacements de hachage (valeur de hachage). Par défaut, 16 384 emplacements sont alloués
2. Chaque fragment de données sera stocké dans plusieurs sur plusieurs nœuds. mutuellement maître et esclave
3. Les données sont d'abord écrites sur le nœud maître, puis synchronisées avec le nœud esclave (prend en charge la configuration de la synchronisation de blocage)
4. les données ne maintiennent pas la cohérence entre
5. Lors de la lecture des données, lorsque la clé actionnée par le client n'est pas allouée sur le nœud, redis renverra une commande de pilotage pour pointer vers le bon nœud
6. Lors de l'extension de la capacité, il est nécessaire de migrer une partie des données de l'ancien nœud vers le nouveau nœud
Dans l'architecture du cluster Redis, chaque Redis doit ouvrir deux numéros de port, par exemple l'un est 6379, et l'autre est ajouté un numéro de port 1w, tel que 16379.
Le numéro de port 16379 est utilisé pour la communication entre les nœuds, c'est-à-dire la communication sur le bus de cluster. Il est utilisé pour la détection des pannes, les mises à jour de configuration et l'autorisation de basculement. Le bus de cluster utilise un autre protocole binaire, le protocole gossip , qui est utilisé pour un échange de données efficace entre les nœuds et consomme moins de bande passante réseau et de temps de traitement.
Mécanisme de communication interne entre les nœuds
Principes de communication de base
Il existe deux manières de conserver les métadonnées du cluster : le protocole centralisé et le protocole de potins. Le protocole gossip est utilisé pour communiquer entre les nœuds du cluster Redis.
Algorithme d'adressage distribué
algorithme de hachage (reconstruction de cache de masse)
Algorithme de hachage de cohérence ( migration automatique du cache) + nœud virtuel (équilibrage de charge automatique)
algorithme de slot de hachage du cluster redis
Avantages
1. Aucune architecture centrale, prend en charge l'expansion dynamique et est transparent pour l'entreprise
2. Dispose de capacités de surveillance Sentinel et de basculement automatique
3. pour vous connecter à tous les nœuds du cluster, connectez-vous simplement à n'importe quel nœud disponible du cluster
4. Hautes performances, le client est directement connecté au service redis, éliminant la perte de proxy
Inconvénients
1. L'exploitation et la maintenance sont également très complexes, et la migration des données nécessite une intervention manuelle
2. Seule la base de données n°0 peut être utilisée
3. Les opérations par lots ne sont pas prises en charge (fonctionnement du pipeline)
4. Logique distribuée et couplage de modules de stockage, etc.
Basé sur l'allocation client
Présentation
Redis Sharding est une méthode de clustering multi-instances Redis couramment utilisée dans l'industrie avant l'avènement de Redis Cluster. L'idée principale est d'utiliser un algorithme de hachage pour hacher la clé des données Redis. Grâce à la fonction de hachage, une clé spécifique sera mappée à un nœud Redis spécifique. Le client Java Redis pilote les Jedis et prend en charge la fonction Redis Sharding, à savoir ShardedJedis et ShardedJedisPool combinés avec un pool de cache
Avantages
L'avantage est que c'est très simple, Les instances Redis côté serveur sont indépendantes les unes des autres et n'ont aucune corrélation entre elles. Chaque instance Redis fonctionne comme un seul serveur et est très facile à développer de manière linéaire. Le système est très flexible
Inconvénients<.>
1. Étant donné que le traitement du partitionnement est confié au client, une expansion ultérieure de l'échelle entraînera des défis en matière d'exploitation et de maintenance.
2. Le partitionnement côté client ne prend pas en charge l'ajout et la suppression dynamiques de nœuds. Lorsque la topologie du groupe d'instances Redis côté serveur change, chaque client doit être mis à jour et ajusté. Les connexions ne peuvent pas être partagées. Lorsque l'échelle de l'application augmente, le gaspillage des ressources est limité et optimisé Basé sur le partitionnement du serveur proxy
Introduction
Le client envoie une requête à un composant proxy, le proxy analyse les données du client, transmet la requête au bon nœud et répond enfin au résultat au client
Fonctionnalités
1. Accès transparent, les programmes commerciaux n'ont pas besoin de se soucier de l'instance Redis back-end, faible coût de commutation2. sont isolés3. Il y a un transfert supplémentaire dans la couche proxy, ce qui entraîne une perte de performances
Solution open source de l'industrie
1. open source Twemproxy2. Codis open source de Wandoujia
Architecture maître-esclave Redis
Un Redis sur une seule machine peut transporter une plage QPS de dizaines de milliers à des dizaines de milliers. Pour les caches, ils sont généralement utilisés pour prendre en charge une concurrence de lecture élevée. Par conséquent, l'architecture est transformée en une architecture maître-esclave, avec un maître et plusieurs esclaves. Le maître est responsable de l'écriture et de la copie des données vers d'autres nœuds esclaves, et les nœuds esclaves sont responsables de la lecture. Toutes les demandes de lecture vont aux nœuds esclaves. Cela peut également facilement réaliser une expansion horizontale et prendre en charge une concurrence de lecture élevée.
Réplication Redis -> Architecture maître-esclave -> Séparation en lecture et en écriture -> 🎜> Le mécanisme de base de la réplication redis
1. Redis réplique les données sur le nœud esclave de manière asynchrone, mais à partir de redis2.8, le nœud esclave confirmera périodiquement la quantité de données qu'il copie à chaque fois ; 2. Un nœud maître peut être configuré avec plusieurs nœuds esclaves
3. Le nœud esclave peut également se connecter à d'autres nœuds esclaves
4. réplique, Il ne bloquera pas le travail normal du nœud maître ;
5. Lorsque le nœud esclave se réplique, il ne bloquera pas ses propres opérations de requête pour fournir des services ; la réplication est terminée. Parfois, vous devez supprimer l'ancien ensemble de données et charger le nouvel ensemble de données. À ce moment, les services externes seront suspendus
6. Le nœud esclave est principalement utilisé pour l'expansion horizontale et. séparation de la lecture et de l'écriture. Le nœud esclave étendu peut améliorer le débit de lecture.
Notez que si une architecture maître-esclave est adoptée, il est recommandé que la persistance du nœud maître soit activée. Il n'est pas recommandé d'utiliser le nœud esclave comme sauvegarde à chaud des données du nœud maître. , car dans ce cas, si vous désactivez la persistance du maître, les données peuvent être vides lorsque le maître plante et redémarre, puis les données du nœud esclave peuvent être perdues dès qu'elles sont répliquées.
De plus, divers plans de sauvegarde pour le maître doivent également être réalisés. En cas de perte de tous les fichiers locaux, sélectionnez un RDB dans la sauvegarde pour restaurer le maître. Cela garantira la présence de données au démarrage. Même si le mécanisme de haute disponibilité expliqué plus loin est adopté, le nœud esclave peut automatiquement prendre le relais du maître. Mais il est également possible que le nœud maître ait redémarré automatiquement avant que Sentinel ne détecte la panne du maître, ou que toutes les données du nœud esclave ci-dessus soient effacées.
Le principe de base de la réplication maître-esclave Redis
Lorsqu'un nœud esclave est démarré, il enverra une commande PSYNC au nœud maître. Si c'est la première fois que le nœud esclave se connecte au nœud maître, une copie complète de resynchronisation complète sera déclenchée. À ce moment-là, le maître démarrera un thread en arrière-plan et commencera à générer un fichier instantané RDB
En même temps, il mettra également en cache toutes les commandes d'écriture nouvellement reçues du client dans la mémoire. Une fois le fichier RDB généré, le maître enverra le RDB à l'esclave. L'esclave l'écrira d'abord sur le disque local, puis le chargera depuis le disque local dans la mémoire
Ensuite, le maître le fera. envoyer la commande d'écriture mise en cache dans la mémoire à l'esclave, l'esclave synchronisera également ces données.
S'il y a une panne de réseau entre le nœud esclave et le nœud maître et que la connexion est déconnectée, il se reconnectera automatiquement après la connexion, le nœud maître copiera uniquement les données manquantes sur l'esclave.
Principe du processus
1. Lorsque la base de données esclave et la base de données maître établissent une relation MS, la commande SYNC sera envoyée à la base de données maître
2 Une fois que la base de données maître aura reçu la commande SYNC, elle commencera à enregistrer les instantanés. en arrière-plan (processus de persistance RDB) et met en cache les commandes d'écriture reçues pendant la période
3 Lorsque l'instantané est terminé, le Redis maître enverra le fichier d'instantané et toutes les commandes d'écriture mises en cache au Redis esclave<.>
4. Le Redis esclave Après l'avoir reçu, le fichier instantané sera chargé et la commande mise en cache reçue sera exécutée 5. Après cela, chaque fois que le Redis maître recevra une commande d'écriture, il le fera envoyer la commande au Redis esclave pour assurer la cohérence des données
Inconvénients
Toutes la réplication et la synchronisation des données du nœud esclave sont gérées par le nœud maître, ce qui entraînera trop de pression sur le nœud maître, utilisez donc la structure maître-esclave pour le résoudre
Quel est le modèle de réplication maître-esclave du cluster Redis ?
Afin de rendre le cluster toujours disponible lorsque certains nœuds échouent ou que la plupart des nœuds ne peuvent pas communiquer, le cluster utilise un modèle de réplication maître-esclave et chaque nœud aura N-1 répliques. ProduitComment Redis est-il déployé dans l'environnement de production ?
cluster Redis, 10 machines, 5 machines sont déployées avec des instances maître Redis et les 5 autres machines sont déployées avec des instances esclaves Redis, chaque instance maître a une instance esclave et 5 nœuds sont externes. services de lecture et d'écriture, le pic de qps de lecture et d'écriture de chaque nœud peut atteindre 50 000 par seconde, et la ou les requêtes de lecture et d'écriture maximales pour 5 machines sont de 250 000.
Quelle est la configuration de la machine ? Mémoire 32 Go + CPU 8 cœurs + disque 1 To, mais la mémoire allouée au processus Redis est de 10 Go. Dans les environnements de production en ligne généraux, la mémoire de Redis ne doit pas dépasser 10 Go. Si elle dépasse 10 Go, il peut y avoir des problèmes. Cinq machines assurent la lecture et l'écriture externe, avec un total de 50 g de mémoire. Étant donné que chaque instance maître possède une instance esclave, elle est hautement disponible. Si une instance maître tombe en panne, elle basculera automatiquement. L'instance esclave Redis deviendra automatiquement l'instance maître et continuera à fournir des services de lecture et d'écriture. . Quelles données écrivez-vous dans la mémoire ? Quelle est la taille de chaque élément de données ? Données du produit, chaque élément de données fait 10 Ko. 100 éléments de données correspondent à 1 Mo et 100 000 éléments de données correspondent à 1 Go. Il y a 2 millions de données produit résidant dans la mémoire et la mémoire occupée est de 20 g, ce qui ne représente que moins de 50 % de la mémoire totale. La période de pointe actuelle est d'environ 3 500 requêtes par seconde. En fait, les grandes entreprises disposeront d'une équipe d'infrastructure responsable du fonctionnement et de la maintenance du cluster de cache.
Parlez-moi du concept du slot de hachage Redis ?
Le cluster Redis n'utilise pas de hachage cohérent, mais introduit le concept d'emplacements de hachage. Le cluster Redis dispose de 16 384 emplacements de hachage. Chaque clé est vérifiée après la vérification CRC16 et 16 384 sont obtenus. Le module détermine quel emplacement placer et chaque nœud du cluster est responsable d'une partie de l'emplacement de hachage.
Les opérations d'écriture seront-elles perdues dans le cluster Redis ? Pourquoi?
Redis ne garantit pas une forte cohérence des données, ce qui signifie qu'en pratique, le cluster peut perdre des opérations d'écriture sous certaines conditions.
Comment les clusters Redis sont-ils répliqués ?
Réplication asynchrone
Quel est le nombre maximum de nœuds dans un cluster Redis ?
16384
Comment choisir une base de données pour le cluster Redis ?
Le cluster Redis ne peut actuellement pas sélectionner la base de données et utilise par défaut la base de données 0.
Redis est monothread. Comment améliorer l'utilisation du processeur multicœur ?
Vous pouvez déployer plusieurs instances Redis sur le même serveur et les utiliser comme serveurs différents À un moment donné, un serveur ne suffit pas de toute façon, donc, si vous souhaitez utiliser plusieurs processeurs, vous pouvez envisager le partitionnement.
Pourquoi avez-vous besoin du partitionnement Redis ?
Le partitionnement permet à Redis de gérer une mémoire plus grande, et Redis pourra utiliser la mémoire de toutes les machines. Sans partitions, vous ne pouvez utiliser que la mémoire d'une seule machine. Le partitionnement permet de doubler la puissance de calcul de Redis en ajoutant simplement des ordinateurs, et la bande passante du réseau de Redis augmentera également de façon exponentielle avec l'ajout d'ordinateurs et de cartes réseau.
Savez-vous quelles solutions d'implémentation de partition Redis sont disponibles ?
1. Le partitionnement côté client signifie que le client a déjà décidé dans quel nœud Redis les données seront stockées ou lues. La plupart des clients implémentent déjà le partitionnement côté client.
2. Le partitionnement de l'agent signifie que le client envoie la demande à l'agent, puis l'agent décide à quel nœud accéder pour écrire ou lire des données. L'agent décide quelles instances Redis demander en fonction des règles de partition, puis les renvoie au client en fonction des résultats de la réponse Redis. Une implémentation de proxy pour Redis et Memcached est Twemproxy. 3. Le routage des requêtes (routage des requêtes) signifie que le client demande de manière aléatoire n'importe quelle instance Redis, puis Redis transmet la demande au nœud Redis approprié. Redis Cluster implémente une forme hybride de routage des requêtes, mais au lieu de transmettre les requêtes directement d'un nœud Redis à un autre, il redirige directement vers le nœud Redis approprié avec l'aide du client.
Quels sont les inconvénients du partitionnement Redis ?
1. Les opérations impliquant plusieurs touches ne sont généralement pas prises en charge. Par exemple, vous ne pouvez pas croiser deux collections car elles peuvent être stockées dans des instances Redis différentes (en fait, il existe un moyen pour cette situation, mais la commande intersection ne peut pas être utilisée directement).
2. Si plusieurs clés sont utilisées en même temps, les transactions Redis ne peuvent pas être utilisées.
3. La granularité du partitionnement est la clé, il n'est donc pas possible de partitionner un ensemble de données avec une seule clé énorme comme un très grand ensemble trié)
4. Lors de l'utilisation de partitions, le traitement des données sera très compliqué. Par exemple, pour la sauvegarde, vous devez collecter simultanément les fichiers RDB/AOF de différentes instances et hôtes Redis.
5. L'expansion ou la contraction dynamique lors du cloisonnement peut être très compliquée. Le cluster Redis ajoute ou supprime des nœuds Redis au moment de l'exécution, ce qui permet d'obtenir un rééquilibrage des données qui est le plus transparent possible pour les utilisateurs. Cependant, certaines autres méthodes de partitionnement client ou de partitionnement proxy ne prennent pas en charge cette fonctionnalité. Cependant, il existe une technologie de pré-partage qui peut également mieux résoudre ce problème.
Redis implémente des verrous distribués
Redis est un mode mono-thread à processus unique, utilisant le mode file d'attente pour transformer l'accès simultané en accès série, et multi- client Il n'y a pas de concurrence pour les connexions à Redis. Vous pouvez utiliser la commande SETNX dans Redis pour implémenter des verrous distribués.
Si et seulement si la clé n'existe pas, définissez la valeur de la clé sur value. Si la clé donnée existe déjà, SETNX n'effectue aucune action
SETNX est l'abréviation de "SET if Not eXists" (si elle n'existe pas, alors SET).
Valeur de retour : Si le réglage est réussi, 1 sera renvoyé. L'installation échoue et renvoie 0.
Le processus et les questions d'utilisation de SETNX pour terminer le verrouillage de synchronisation sont les suivants :
Utilisez la commande SETNX pour obtenir le verrou Si 0 est renvoyé (la clé existe déjà, le verrou existe déjà. existe), l'acquisition échoue, sinon l'acquisition est réussie
Afin d'éviter les exceptions dans le programme après l'acquisition du verrou, ce qui fait que les autres threads/processus renvoient toujours 0 lors de l'appel de la commande SETNX et entrent dans un état de blocage , un délai d'expiration "raisonnable" doit être défini pour la clé
Release Lock, utilisez la commande DEL pour supprimer les données de verrouillage
Comment résoudre le problème de concurrence simultanée pour Clé dans Redis
Le soi-disant problème de concurrence concurrente pour Key in Redis est multiple Le système fonctionne sur une clé en même temps, mais l'ordre d'exécution final est différent de l'ordre nous nous attendons, ce qui conduit à des résultats différents !
Recommander une solution : le verrouillage distribué (zookeeper et redis peuvent implémenter le verrouillage distribué). (S'il n'y a pas de concurrence simultanée pour Key dans Redis, n'utilisez pas de verrous distribués, car cela affecterait les performances)
Verrous distribués basés sur les nœuds ordonnés temporaires de zookeeper. L'idée générale est la suivante : lorsque chaque client verrouille une certaine méthode, un nœud ordonné instantané unique est généré dans le répertoire du nœud spécifié correspondant à la méthode sur zookeeper. La manière de déterminer s'il faut acquérir un verrou est très simple. Il vous suffit de déterminer le plus petit numéro de séquence parmi les nœuds ordonnés. Lorsque le verrou est libéré, supprimez simplement le nœud transitoire. Dans le même temps, cela peut éviter les problèmes de blocage causés par des verrous qui ne peuvent pas être libérés en raison d'un temps d'arrêt du service. Une fois le processus métier terminé, supprimez le nœud enfant correspondant pour libérer le verrou.
En pratique, la fiabilité est bien sûr la priorité principale. Par conséquent, Zookeeper est recommandé en premier.
Les Redis distribués doivent-ils être effectués à un stade précoce ou à un stade ultérieur lorsque l'échelle est augmentée ? Pourquoi?
Étant donné que Redis est si léger (une seule instance n'utilise que 1 Mo de mémoire), le meilleur moyen d'empêcher une expansion future est de démarrer plusieurs instances au début. Même si vous ne disposez que d'un seul serveur, vous pouvez faire exécuter Redis de manière distribuée dès le début, en utilisant des partitions pour démarrer plusieurs instances sur le même serveur.
Configurez quelques instances Redis supplémentaires au début, par exemple 32 ou 64 instances, cela peut être fastidieux pour la plupart des utilisateurs, mais à long terme, cela en vaut la peine.
Dans ce cas, lorsque vos données continuent de croître et que vous avez besoin de plus de serveurs Redis, il vous suffit de migrer l'instance Redis d'un service vers un autre serveur (sans considérer le problème de répartition). Une fois que vous avez ajouté un autre serveur, vous devez migrer la moitié de vos instances Redis de la première machine vers la deuxième machine.
Qu'est-ce que RedLock
Le site officiel de Redis a proposé une méthode faisant autorité pour implémenter des verrous distribués basés sur Redis appelé Redlock. Cette méthode est meilleure que l'original. l’approche à nœud unique est plus sécurisée. Il peut garantir les caractéristiques suivantes :
1. Fonctionnalités de sécurité : accès mutuellement exclusif, c'est-à-dire qu'un seul client peut toujours obtenir le verrou
2. Éviter les blocages : éventuellement tous les clients. peut obtenir le verrou Une fois le verrou atteint, il n'y aura pas de blocage, même si le client qui a initialement verrouillé une ressource plante ou si une partition réseau se produit
3. Tolérance aux pannes : tant que la plupart des nœuds Redis survivent, les services peuvent être fournis normalement
Exception de cache
Avalanche de cache
L'avalanche de cache fait référence au cache. Une grande période de temps échoue, de sorte que les requêtes ultérieures tomberont sur la base de données, ce qui obligera la base de données à résister à un grand nombre de requêtes en peu de temps et à s'effondrer.
Solution
1. Définissez le délai d'expiration des données mises en cache de manière aléatoire pour éviter qu'un grand nombre de données n'expirent en même temps.
2. Généralement, lorsque le degré de concurrence n'est pas particulièrement important, la solution la plus couramment utilisée est la mise en file d'attente de verrouillage.
3. Ajoutez une balise de cache correspondante à chaque donnée mise en cache et enregistrez si la balise de cache est invalide, mettez à jour le cache de données.
Pénétration du cache
La pénétration du cache fait référence aux données qui ne sont ni dans le cache ni dans la base de données, ce qui fait que toutes les requêtes tombent sur la base de données , provoquant l'effondrement de la base de données sous un grand nombre de requêtes en peu de temps.
Solution
1. Ajouter une vérification au niveau de la couche d'interface, telle que la vérification de l'authentification de l'utilisateur, la vérification de base de l'identifiant et l'interception directe de l'identifiant<=0;
2. Les données qui ne peuvent pas être récupérées du cache ne sont pas récupérées de la base de données. À ce stade, la paire clé-valeur peut également être écrite comme clé-nulle. La durée de validité du cache peut être définie plus courte, par exemple. 30 secondes (un réglage trop long le rendra inutilisable dans des circonstances normales). Cela peut empêcher les utilisateurs attaquants d'utiliser à plusieurs reprises le même identifiant pour des attaques par force brute ;
3. Utilisez un filtre Bloom pour hacher toutes les données possibles dans un bitmap suffisamment grand. Les données qui n'existent certainement pas seront interceptées. par ce bitmap, évitant ainsi la pression des requêtes sur le système de stockage sous-jacent.
Supplémentaire
Utilisez l'espace à l'extrême, c'est-à-dire Bitmap et Bloom Filter.
Bitmap : La table de hachage typique est la table de hachage
L'inconvénient est que Bitmap ne peut enregistrer qu'un seul bit d'information pour chaque élément si vous souhaitez remplir des fonctions supplémentaires. , j'ai peur que cela ne puisse être accompli qu'en sacrifiant plus d'espace et de temps.
Filtre Bloom (recommandé)
introduit k(k>1)k(k>1) fonctions de hachage indépendantes pour garantir que, dans un espace et un taux d'erreur de jugement donnés, le le processus de détermination du poids des éléments est terminé.
Son avantage est que l'efficacité spatiale et le temps de requête sont bien supérieurs à l'algorithme général. Son inconvénient est qu'il a un certain taux de mauvaise reconnaissance et des difficultés de suppression.
L'idée principale de l'algorithme Bloom-Filter est d'utiliser plusieurs fonctions de hachage différentes pour résoudre les « conflits ».
Hash a un problème de conflit (collision), et les valeurs de deux URL obtenues en utilisant le même Hash peuvent être les mêmes. Afin de réduire les conflits, nous pouvons introduire plusieurs valeurs de hachage supplémentaires. Si nous concluons à partir de l'une des valeurs de hachage qu'un élément n'est pas dans l'ensemble, alors l'élément n'est certainement pas dans l'ensemble. Ce n'est que lorsque toutes les fonctions de hachage nous indiquent que l'élément est dans l'ensemble que nous pouvons être sûrs que l'élément existe dans l'ensemble. C'est l'idée de base de Bloom-Filter.
Bloom-Filter est généralement utilisé pour déterminer si un élément existe dans un grand ensemble de données.
Panne du cache
La panne du cache fait référence aux données qui ne sont pas dans le cache mais qui se trouvent dans la base de données (généralement, la durée du cache a expiré) , À l'heure actuelle, en raison du grand nombre d'utilisateurs simultanés, les données ne sont pas lues dans le cache de lecture en même temps et les données sont extraites de la base de données en même temps, ce qui entraîne une augmentation instantanée de la pression sur la base de données. provoquant une pression excessive. Contrairement à l'avalanche de cache, la panne de cache fait référence à l'interrogation simultanée des mêmes données. L'avalanche de cache signifie que différentes données ont expiré et que de nombreuses données sont introuvables, la base de données est donc recherchée.
Solution
1. Définir les données du point d'accès pour qu'elles n'expirent jamais
2. Ajouter un verrouillage mutex, un verrouillage mutex
Préchauffage du cache
Le préchauffage du cache consiste à charger les données de cache pertinentes directement dans le système de cache une fois le système mis en ligne. De cette façon, vous pouvez éviter le problème d’interroger d’abord la base de données, puis de mettre les données en cache lorsque l’utilisateur le demande ! Les utilisateurs interrogent directement les données mises en cache qui ont été préchauffées !
Solution
1. Écrivez directement une page d'actualisation du cache et faites-le manuellement lors de la connexion
2. grand, vous pouvez charger automatiquement au démarrage du projet
3. Actualiser régulièrement le cache
Rétrograder le cache
Lorsque le volume de trafic augmente Lorsque des problèmes de service surviennent (tels qu'un temps de réponse lent ou aucune réponse) ou que des services non essentiels affectent les performances des processus principaux, il est toujours nécessaire de garantir que le service est toujours disponible, même s'il est compromis. . Le système peut automatiquement rétrograder en fonction de certaines données clés, ou configurer des commutateurs pour réaliser une rétrogradation manuelle.
Le but ultime de la rétrogradation du cache est de garantir que les services de base sont disponibles, même s'ils entraînent des pertes. Et certains services ne peuvent pas être rétrogradés (comme l'ajout au panier, le paiement).
Avant de déclasser, vous devez trier le système pour voir si le système peut perdre des soldats et conserver des commandants, triant ainsi ce qui doit être protégé jusqu'à la mort et ce qui peut être déclassé par exemple ; au plan de configuration du niveau de journalisation :
1. Général : par exemple, certains services expirent parfois en raison de la gigue du réseau ou le service est en ligne et peut être automatiquement rétrogradé
2. : Certains services ont des taux de réussite fluctuants sur une période donnée (comme 95 ~ 100 %), vous pouvez automatiquement rétrograder ou rétrograder manuellement et envoyer une alarme
Erreur : par exemple, le taux de disponibilité ; est inférieur à 90 %, ou le pool de connexions à la base de données explose, ou le nombre de visites augmente soudainement. Lorsqu'il atteint le seuil maximum que le système peut supporter, il peut être automatiquement rétrogradé ou manuellement selon la situation
;4. Erreurs graves : par exemple, si les données sont incorrectes pour des raisons particulières, une rétrogradation manuelle d'urgence est requise.
Le but de la rétrogradation du service est d'empêcher une défaillance du service Redis de provoquer des problèmes d'avalanche dans la base de données. Par conséquent, pour les données mises en cache sans importance, une stratégie de rétrogradation du service peut être adoptée. Par exemple, une approche courante consiste à renvoyer directement la valeur par défaut à l'utilisateur en cas de problème avec Redis.
Données chaudes et données froides
Données chaudes, le cache est précieux
Pour les données froides, la plupart des données peuvent avoir a été extrait de la mémoire avant d'y accéder à nouveau, ce qui non seulement occupe de la mémoire, mais a également peu de valeur. Pour les données fréquemment modifiées, pensez à utiliser le cache en fonction de la situation
Pour les données chaudes, comme l'un de nos produits de messagerie instantanée, le module de voeux d'anniversaire et la liste d'anniversaire du jour, le cache peut être lu des centaines de milliers de fois. Pour un autre exemple, dans un produit de navigation, nous mettons en cache les informations de navigation et pouvons les lire des millions de fois dans le futur.
Le cache n'a de sens que si les données sont lues au moins deux fois avant la mise à jour. Il s'agit de la stratégie la plus élémentaire. Si le cache échoue avant de prendre effet, il n'aura pas beaucoup de valeur.
Qu'en est-il du scénario dans lequel le cache n'existe pas et la fréquence de modification est très élevée, mais où la mise en cache doit être prise en compte ? avoir! Par exemple, cette interface de lecture exerce beaucoup de pression sur la base de données, mais il s'agit également de données chaudes. À ce stade, vous devez envisager des méthodes de mise en cache pour réduire la pression sur la base de données, comme le nombre de likes, de collections et. partages de l'un de nos produits assistants. Il s'agit de données chaudes très typiques, mais elles changent constamment. À l'heure actuelle, les données doivent être enregistrées de manière synchrone dans le cache Redis pour réduire la pression sur la base de données.
Clé du hotspot du cache
Une Clé dans le cache (comme un produit promotionnel), lorsqu'elle expire à un certain moment, Il se trouve qu'à l'heure actuelle, il y a un grand nombre de demandes simultanées pour cette clé. Lorsque ces demandes constatent que le cache a expiré, elles chargent généralement les données de la base de données principale et les réinitialisent dans le cache. cette fois, des requêtes simultanées volumineuses peuvent instantanément submerger la base de données back-end.
Solution
Verrouillez la requête de cache. Si la CLÉ n'existe pas, verrouillez-la, puis enregistrez la base de données dans le cache, puis déverrouillez-la si d'autres processus ; trouvez qu'il y a un verrou Attendez simplement, puis renvoyez les données après le déverrouillage ou entrez la requête DB
Outils communs
Quels sont les Clients Java pris en charge par Redis ? Lequel est officiellement recommandé ?
Redisson, Jedis, laitue, etc., la recommandation officielle est d'utiliser Redisson.
Quelle est la relation entre Redis et Redisson ?
Redisson est un client Redis de coordination distribuée avancé qui peut aider les utilisateurs à implémenter facilement certains objets Java (filtre Bloom, BitSet, Set, SetMultimap, ScoredSortedSet, SortedSet, Map) dans un environnement distribué, ConcurrentMap, List , ListMultimap, Queue, BlockingQueue, Deque, BlockingDeque, Semaphore, Lock, ReadWriteLock, AtomicLong, CountDownLatch, Publish/Subscribe, HyperLogLog).
Quels sont les avantages et les inconvénients des Jedis et Redisson ?
Jedis est un client implémenté par Redis en Java. Son API fournit un support relativement complet pour les commandes Redis ; Redisson implémente une structure de données Java distribuée et évolutive. Par rapport à Jedis, ses fonctions sont relativement simples, ne prend pas en charge les opérations sur les chaînes et ne prend pas en charge les fonctionnalités Redis telles que le tri, les transactions, les pipelines et les partitions. L'objectif de Redisson est de promouvoir la séparation des préoccupations des utilisateurs de Redis, afin que les utilisateurs puissent se concentrer davantage sur le traitement de la logique métier.
Autres questions
La différence entre Redis et Memcached
Les deux sont des souvenirs non relationnels Pour les bases de données clé-valeur, les entreprises utilisent désormais généralement Redis pour mettre en œuvre la mise en cache, et Redis lui-même devient de plus en plus puissant ! Les principales différences entre Redis et Memcached sont les suivantes :
对比参数
|
redis |
memcached |
| 类型 |
1. 支持内存 2. 非关系型数据库 |
1. 支持内存 2. 键值对形式 3. 缓存形式 |
| 数据存储类型 |
1. String 2. List 3. Set 4. Hash 5. Sort Set 【俗称ZSet】 |
1. 文本型 2. 二进制类型 |
| 查询【操作】类型 |
1. 批量操作 2. 事务支持 3. 每个类型不同的CRUD |
1.常用的CRUD 2. 少量的其他命令 |
| 附加功能 |
1. 发布/订阅模式 2. 主从分区 3. 序列化支持 4. 脚本支持【Lua脚本】 |
1. 多线程服务支持 |
| 网络IO模型 |
单线程的多路IO复用模型
|
1. 多线程，非阻塞IO模式 |
事件库
|
AeEvent |
LibEvent |
持久化支持
|
1. RDB 2. AOF |
不支持
|
集群模式
|
原生支持cluster模式，可以实现主从复制，读写分离
|
没有原生的集群模式，需要依靠客户端来实现往集群中分片写入数据 |
内存管理机制
|
在 Redis 中，并不是所有数据都一直存储在内存中，可以将一些很久没用的 value 交换到磁盘 |
Memcached 的数据则会一直在内存中，Memcached 将内存分割成特定长度的块来存储数据，以完全解决内存碎片的问题。但是这种方式会使得内存的利用率不高，例如块的大小为 128 bytes，只存储 100 bytes 的数据，那么剩下的 28 bytes 就浪费掉了。 |
适用场景
|
复杂数据结构，有持久化，高可用需求，value存储内容较大
|
纯key-value，数据量非常大，并发量非常大的业务 |
(1) Toutes les valeurs de memcached sont des chaînes simples En remplacement, redis prend en charge des types de données plus riches
(2) redis est beaucoup plus rapide que memcached
( 3) Redis peut conserver ses données
Comment assurer la cohérence des données lorsque le cache et la base de données sont en double écriture ?
Tant que vous utilisez le cache, cela peut impliquer un double stockage et une double écriture du cache et de la base de données. Tant que vous utilisez la double écriture, il y aura certainement des problèmes de cohérence des données. le problème de cohérence ?
De manière générale, si votre système n'exige pas strictement la cohérence cache + base de données, le cache peut parfois être légèrement incohérent avec la base de données. Il est préférable de ne pas utiliser cette solution, de lire les requêtes et d'écrire les requêtes. dans une file d'attente mémoire, afin de garantir qu'il n'y aura pas d'incohérence
Après la sérialisation, le débit du système sera considérablement réduit et l'utilisation sera nettement inférieure à la normale. Dans ce cas, plusieurs fois. davantage de machines sont nécessaires pour prendre en charge une demande en ligne.
Il existe une autre manière pour qu'une incohérence temporaire se produise, mais la probabilité qu'elle se produise est très faible, qui consiste à mettre d'abord à jour la base de données, puis à supprimer le cache .
问题场景
|
描述 |
解决 |
| 先写缓存，再写数据库，缓存写成功，数据库写失败 |
缓存写成功，但写数据库失败或者响应延迟，则下次读取（并发读）缓存时，就出现脏读 |
这个写缓存的方式，本身就是错误的，需要改为先写数据库，把旧缓存置为失效；读取数据的时候，如果缓存不存在，则读取数据库再写缓存 |
| 先写数据库，再写缓存，数据库写成功，缓存写失败 |
写数据库成功，但写缓存失败，则下次读取（并发读）缓存时，则读不到数据 |
缓存使用时，假如读缓存失败，先读数据库，再回写缓存的方式实现 |
| 需要缓存异步刷新 |
指数据库操作和写缓存不在一个操作步骤中，比如在分布式场景下，无法做到同时写缓存或需要异步刷新（补救措施）时候 |
确定哪些数据适合此类场景，根据经验值确定合理的数据不一致时间，用户数据刷新的时间间隔 |
Scénario de problème
|
Description |
Solution |
| Écrivez d'abord le cache, puis écrivez Base de données, l'écriture du cache est réussie, l'écriture de la base de données échoue |
L'écriture du cache est réussie, mais l'écriture de la base de données échoue ou la réponse est retardée, puis la prochaine fois que le cache est lu (lecture simultanée), une lecture sale se produira |
Cette façon d'écrire le cache est erronée en soi. Vous devez d'abord écrire dans la base de données et invalider l'ancien cache lors de la lecture des données, si le cache est en cours. n'existe pas, lisez La base de données écrit ensuite le cache |
| Écrivez d'abord la base de données, puis écrivez le cache. L'écriture de la base de données est réussie, mais l'écriture du cache. échoue |
Si l'écriture dans la base de données réussit, mais que l'écriture dans le cache échoue, la prochaine fois que le cache sera lu (lecture simultanée), les données ne pourront pas être lues |
Lorsque le cache est utilisé, si le cache de lecture échoue, la base de données est d'abord lue, puis réécrit le cache pour y parvenir |
| Nécessite une actualisation asynchrone du cache |
Fait référence à l'opération de base de données et à l'écriture du cache dans une étape d'opération, par exemple, dans un scénario distribué, lorsque le cache ne peut pas être écrit. la même heure ou une actualisation asynchrone est requise (mesures correctives) |
Déterminer quelles données sont adaptées à de tels scénarios, en fonction des valeurs d'expérience Déterminer le temps d'incohérence raisonnable des données et l'intervalle de temps pour les données utilisateur actualiser |
Problèmes de performances courants de Redis et solutions ?
1. Il est préférable que Master n'effectue aucun travail de persistance, y compris les instantanés de mémoire et les fichiers journaux AOF, en particulier n'activez pas les instantanés de mémoire pour la persistance.
2. Si les données sont critiques, un esclave active les données de sauvegarde AOF, et la stratégie est de synchroniser une fois par seconde.
3. Pour la rapidité de réplication maître-esclave et la stabilité de la connexion, il est préférable que l'Esclave et le Maître soient dans le même LAN.
4. Essayez d'éviter d'ajouter des bibliothèques esclaves à la bibliothèque principale stressée
5. Le maître appelle BGREWRITEAOF pour réécrire le fichier AOF qui occupera une grande quantité de CPU et de mémoire lors de la réécriture. , ce qui entraîne une charge de service trop élevée et une suspension temporaire du service.
6. Pour la stabilité du maître, n'utilisez pas de structure graphique pour la réplication maître-esclave. Il est plus stable d'utiliser une structure de liste chaînée unidirectionnelle, c'est-à-dire que la relation maître-esclave est. : Master<–Slave1<–Slave2<–Slave3…, comme ceci. La structure est également pratique pour résoudre le problème du point de défaillance unique et réaliser le remplacement du maître par l'esclave. Autrement dit, si le maître raccroche, vous pouvez. activez immédiatement Slave1 en tant que maître, et les autres choses restent inchangées.
Pourquoi Redis ne fournit-il pas officiellement une version Windows ?
Étant donné que la version actuelle de Linux est assez stable et compte un grand nombre d'utilisateurs, il n'est pas nécessaire de développer une version Windows, ce qui entraînerait des problèmes de compatibilité et d'autres problèmes.
Quelle est la capacité maximale qu'une valeur de type chaîne peut stocker ?
512M
Comment Redis effectue-t-il l'insertion d'une grande quantité de données ?
À partir de Redis 2.6, redis-cli prend en charge un nouveau mode appelé mode pipe pour effectuer de grandes quantités de travaux d'insertion de données.
Supposons qu'il y ait 100 millions de clés dans Redis et que 100 000 d'entre elles commencent par un préfixe fixe et connu. Comment les trouver toutes ?
Utilisez la commande keys pour parcourir la liste des clés du modèle spécifié.
L'autre partie a ensuite demandé : si ce redis fournit des services aux entreprises en ligne, quels sont les problèmes liés à l'utilisation de la commande key ?
À ce stade, vous devez répondre à une fonctionnalité clé de Redis : le monothreading de Redis. L'instruction key entraînera le blocage du thread pendant un certain temps et le service en ligne sera mis en pause. Le service ne pourra pas être restauré tant que l'instruction n'est pas exécutée. À ce stade, vous pouvez utiliser la commande scan. La commande scan peut extraire la liste des clés du mode spécifié sans blocage, mais il y aura une certaine probabilité de duplication. Il suffit de le faire une fois sur le client, mais le temps global passé sera le même. être plus long que de l'utiliser directement. La commande key est longue.
Avez-vous déjà créé une file d'attente asynchrone avec Redis ? Comment a-t-elle été implémentée ?
Utilisez le type de liste pour enregistrer les informations sur les données, rpush produit des messages et lpop consomme des messages. Lorsque lpop n'a pas de messages, vous pouvez dormir pendant un certain temps, puis vérifier s'il y a des informations. . Si vous ne voulez pas dormir, vous pouvez utiliser blpop , lorsqu'il n'y a aucune information, il se bloquera jusqu'à ce que l'information arrive. Redis peut implémenter un producteur et plusieurs consommateurs via le modèle d'abonnement au sujet pub/sub. Bien sûr, il existe certains inconvénients lorsque le consommateur se déconnecte, les messages produits seront perdus.
Comment Redis implémente-t-il la file d'attente différée ?
Utilisez sortedset, utilisez l'horodatage comme score, le contenu du message comme clé, appelez zadd pour produire des messages et le consommateur utilise zrangbyscore pour obtenir des données il y a n secondes pour le traitement de l'interrogation.
Comment fonctionne le processus de recyclage Redis ?
1. Un client a exécuté une nouvelle commande et ajouté de nouvelles données.
2. Redis vérifie l'utilisation de la mémoire si elle est supérieure à la limite de maxmemory, elle sera recyclée selon la stratégie définie.
3. Une nouvelle commande est exécutée, etc.
4. Nous franchissons donc constamment la limite de la mémoire en atteignant constamment la limite, puis en recyclant continuellement en dessous de la limite.
Si le résultat d'une commande entraîne l'utilisation d'une grande quantité de mémoire (comme par exemple l'enregistrement de l'intersection d'un grand ensemble sur une nouvelle clé), il ne faudra pas longtemps pour que la limite de mémoire soit dépassée par cette utilisation de la mémoire.
Quel algorithme Redis utilise-t-il pour le recyclage ?
Algorithme LRU
Pour plus de connaissances liées à la programmation, veuillez visiter : Enseignement de la programmation ! !
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!
![[Web front-end] Démarrage rapide de Node.js](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
