Maison > Article > base de données > Un résumé de plus de 20 questions d'entretien Redis incontournables, venez les récupérer ! !
Cet article partagera avec vous quelques questions d'entretien Redis afin que vous puissiez vérifier les éventuelles lacunes et améliorer vos connaissances. 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.
Cache
Session partagée
Système de file d'attente de messages
Verrouillage distribué
Recommandations associées : Tutoriel vidéo Redis
Opération de mémoire pure
Single Le fonctionnement du thread évite les changements de contexte fréquents
Structure de données raisonnable et efficace
Adopte un mécanisme de multiplexage d'E/S non bloquant (il existe un descripteur de fichier qui surveille plusieurs descripteurs de fichiers en même temps pour l'arrivée des données)
Chaîne chaîne : Le type chaîne est la structure de données la plus basique de Redis. Tout d'abord, les clés sont toutes des types chaîne, et plusieurs autres structures de données sont construites sur la base du type chaîne. Nous utilisons souvent la commande set valeur. une chaîne. Couramment utilisé dans la mise en cache, le comptage, la session partagée, la limitation de débit, etc.
Hash : dans Redis, le type de hachage fait référence à la valeur clé elle-même qui est également une structure de paire clé-valeur. Le hachage peut être utilisé pour stocker des informations sur l'utilisateur, comme la mise en œuvre d'un achat. panier.
Liste liste (liste doublement chaînée) : Le type liste (liste) est utilisé pour stocker plusieurs chaînes ordonnées. Peut exécuter une fonction simple de file d’attente de messages.
Set : le type set est également utilisé pour enregistrer plusieurs éléments de chaîne, mais contrairement au type liste, les éléments en double ne sont pas autorisés dans l'ensemble, et l'ensemble Les éléments de ne sont pas ordonnés et ne peut pas être obtenu via les indices d’index. En utilisant l'intersection, l'union, la différence et d'autres opérations de Set, vous pouvez calculer les préférences communes, toutes les préférences, vos propres préférences uniques et d'autres fonctions.
Ensemble trié (implémentation de liste de raccourcis) : L'ensemble trié a un paramètre de poids supplémentaire, Score, et les éléments de l'ensemble peuvent être organisés en fonction du score. Il peut être utilisé comme application de classement pour effectuer des opérations TOP N.
La stratégie d'expiration des données de Redis adopte la stratégie suppression régulière + suppression paresseuse
Stratégie de suppression régulière : Redis permet à un minuteur de surveiller régulièrement toutes les clés pour déterminer si la clé a expiré et de la supprimer si elle expire. Cette stratégie peut garantir que les clés expirées seront éventuellement supprimées, mais elle présente également de sérieux inconvénients : parcourir toutes les données en mémoire à chaque fois, ce qui consomme beaucoup de ressources CPU, et lorsque la clé a expiré, mais le minuteur est toujours en cours. l'état non réveillé, la clé peut toujours être utilisée pendant ce temps.
Stratégie de suppression paresseuse : lors de l'obtention de la clé, déterminez d'abord si la clé a expiré et supprimez-la si elle expire. Cette méthode présente un inconvénient : si la clé n'a pas été utilisée, elle sera toujours en mémoire. En fait, elle a expiré, ce qui fera perdre beaucoup d'espace.
Les deux stratégies sont naturellement complémentaires. Après avoir été combinées, la stratégie de suppression programmée a subi quelques modifications. Elle ne scanne plus toutes les clés à chaque fois, mais sélectionne aléatoirement une partie des clés. La vérification est effectuée, réduisant ainsi la consommation des ressources CPU. La stratégie de suppression paresseuse complète les clés non vérifiées et répond essentiellement à toutes les exigences. Mais parfois c'est une telle coïncidence qu'elles ne sont ni extraites par le timer ni utilisées. Comment ces données disparaissent-elles de la mémoire ? Ce n'est pas grave, il existe également un mécanisme d'élimination de la mémoire. Lorsque la mémoire n'est pas suffisante, le mécanisme d'élimination de la mémoire entre en jeu. La stratégie d'élimination est divisée en : lorsque la mémoire n'est pas suffisante pour accueillir les données nouvellement écrites, la nouvelle opération d'écriture signalera une erreur. (Politique par défaut de Redis) 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. (LRU recommandé) 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 dans l'espace clé. 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, la clé la moins récemment utilisée est supprimée. Cette situation est généralement utilisée lorsque Redis est utilisé à la fois comme cache et comme stockage persistant. 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. 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, la clé avec un délai d'expiration antérieur sera supprimée en premier.
setnx dans Redis ne prend pas en charge la définition du délai d'expiration Lorsque vous effectuez des verrous distribués, vous devez éviter qu'un client soit interrompu et. provoquant la mort. Pour les verrous, le délai d'expiration du verrou doit être défini sur Setnx et expire ne peut pas implémenter d'opérations atomiques lorsque la concurrence est élevée. Si vous souhaitez l'utiliser, vous devez afficher le verrou dans le code du programme. Utiliser SET au lieu de SETNX équivaut à SETNX+EXPIRE pour atteindre l'atomicité. Il n'y a pas lieu de s'inquiéter du succès de SETNX et de l'échec d'EXPIRE.
Le LRU traditionnel utilise une pile, et la dernière utilisée est déplacée vers le haut de la pile à chaque fois, mais l'utilisation de la pile entraînera une grande quantité de données non chaudes occupant les données d'en-tête lors de l'exécution de la sélection *, elle doit donc être améliorée. Chaque fois que Redis obtient une valeur par clé, il mettra à jour le champ lru dans la valeur avec l'horodatage actuel de deuxième niveau. L'algorithme d'implémentation initial de Redis est très simple. Cinq clés sont extraites au hasard du dict et celle avec la plus petite valeur de champ lru est éliminée. Dans la version 3.0, une autre version de l'algorithme a été améliorée. Premièrement, la première clé sélectionnée au hasard sera placée dans un pool (la taille du pool est de 16). Les clés du pool sont classées par ordre de taille LRU. Ensuite, chaque valeur keylru sélectionnée au hasard doit être inférieure au plus petit lru du pool avant de continuer à être ajoutée jusqu'à ce que le pool soit plein. Une fois qu'il est plein, chaque fois qu'une nouvelle clé doit être insérée, la clé avec le plus grand lru du pool doit être retirée. Lors de l'élimination, sélectionnez directement la plus petite valeur lru du pool et éliminez-la.
Solution de clé de point d'accès Redis
Comment résoudre le problème d'avalanche de cache Redis
Comment faire. résoudre le problème de pénétration du cache Redis
Mécanisme de persistance de Redis
AOF : Enregistrez toutes les commandes pour modifier le serveur Redis dans un fichier, une collection de commandes.
Utilisez AOF pour la persistance. Chaque commande d'écriture est ajoutée à appendonly.aof via la fonction d'écriture. La politique par défaut d'aof est de fsync une fois par seconde. Dans cette configuration, même en cas de panne, les données seront perdues pendant une seconde maximum. L'inconvénient est que pour le même ensemble de données, la taille du fichier AOF est généralement supérieure à la taille du fichier RDB. Selon la stratégie fsync utilisée, AOF peut être plus lent que RDB. Redis utilise par défaut la méthode de persistance du snapshot RDB. Pour la synchronisation maître-esclave, lorsque le maître-esclave vient d'être connecté, une synchronisation complète (RDB) est effectuée ; une fois la synchronisation complète terminée, une synchronisation incrémentielle (AOF) est effectuée.
L'essence d'une transaction Redis est un ensemble de commandes. 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.
Les transactions Redis n'ont pas la notion de niveau d'isolement. L'opération par lots est placée dans le cache de file d'attente avant d'envoyer la commande EXEC et ne sera pas réellement exécutée. transaction à voir. Les mises à jour dans la transaction ne peuvent pas être vues par les requêtes en dehors de la transaction.
Dans Redis, une seule commande est exécutée de manière atomique, mais il n'est pas garanti que les transactions soient atomiques et il n'y a pas de restauration. Si une commande de la transaction ne parvient pas à s'exécuter, les commandes restantes seront quand même exécutées.
watch key1 key2 ... : Surveiller une ou plusieurs clés, si avant la transaction est exécutée, si la clé surveillée est modifiée par d'autres commandes, la transaction sera interrompue (similaire au verrouillage optimiste)
multi : marque le début d'un bloc de transaction (mis en file d'attente)
exec : Exécuter les commandes de tous les blocs de transactions (une fois exec exécuté, le verrou de surveillance précédemment ajouté sera annulé)
rejeter : Annuler la transaction, abandonnez toutes les commandes du bloc de transaction
unwatch : annulez la surveillance de toutes les clés par la montre
En termes de méthode de stockage : memcache stockera toutes les données dans la mémoire et raccrochera après une panne de courant. Les données ne peuvent pas dépasser la taille de la mémoire. Certaines données Redis sont stockées sur le disque dur, ce qui garantit la pérennité des données.
En termes de types de prise en charge des données : memcache prend en charge simplement les types de données et ne prend en charge que les valeurs-clés simples, tandis que redis prend en charge cinq types de données.
Les modèles sous-jacents sont différents : ils ont des méthodes de mise en œuvre sous-jacentes et des protocoles d'application différents pour la communication avec les clients. 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.
Taille de la valeur : Redis peut atteindre 1 Go, tandis que Memcache n'est que de 1 Mo.
Réplication maître-esclave
Mode Sentinel
mode cluster
Sentinel est un système distribué, sur la base de la réplication maître-esclave, vous pouvez exécuter plusieurs processus sentinelles dans une architecture. Ces processus utilisent le protocole de rumeur pour recevoir des informations indiquant si le maître est hors ligne, et utilisent le protocole de vote pour décider d'effectuer un basculement automatique et de sélectionner quel esclave sert. comme le nouveau Maître.
Chaque sentinelle enverra régulièrement des messages à d'autres sentinelles, maîtres et esclaves pour confirmer si l'autre partie est en vie. S'il s'avère que l'autre partie ne répond pas dans le délai spécifié (configurable), l'autre partie. le participant sera temporairement considéré comme décédé (ce que l'on appelle « subjectivement considéré comme étant à terre »).
Si la plupart des sentinelles du "Groupe Sentinelle" signalent qu'un certain maître ne répond pas, le système considérera le maître comme "complètement mort" (c'est-à-dire objectivement une véritable machine en panne grâce à un certain vote). algorithme, parmi les nœuds esclaves restants, sélectionnez-en un à promouvoir en maître, puis modifiez automatiquement les configurations pertinentes.
L'opération de rehachage de Redis n'est pas effectuée de manière unique et centralisée, mais est effectuée plusieurs fois et progressivement, et Redis la maintiendra . Conservez une variable de compteur d'index rehashidx pour indiquer la progression du rehash.
Cette rehachage progressif évite l'énorme quantité d'opérations de calcul et de mémoire causées par une rehachage centralisée. Cependant, il convient de noter que lorsque Redis est rehaché, les demandes d'accès normales peuvent devoir accéder à la table de hachage deux fois ( ht[0], ht[. 1]), par exemple, si la valeur de la clé est rehachée vers le nouveau ht1, vous devez d'abord accéder à ht0. Si elle ne peut pas être trouvée dans ht0, elle sera trouvée dans ht1.
Le nombre de clés enregistrées dans la table de hachage dépasse la taille de la table de hachage.
Le serveur Redis n'exécute actuellement pas la commande BGSAVE (rdb) ni la commande BGREWRITEAOF, et le facteur de charge de la table de hachage est supérieur ou égal à 1.
Serveur Redis La commande BGSAVE (rdb) ou la commande BGREWRITEAOF est actuellement exécutée, et le facteur de charge de la table de hachage est supérieur ou égal à 5. (Facteur de charge = le nombre de nœuds enregistrés dans la table de hachage / la taille de la table de hachage, lorsque le facteur de charge de la table de hachage est inférieur à 0,1, effectuez une opération de réduction sur la table de hachage + Timestamp
! !
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!