Un résumé de plus de 20 questions d'entretien Redis incontournables, venez les récupérer ! !-Redis-php.cn

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.

Un résumé de plus de 20 questions d'entretien Redis incontournables, venez les récupérer ! !

Scénarios d'application

Cache
Session partagée
Système de file d'attente de messages
Verrouillage distribué

Recommandations associées : Tutoriel vidéo Redis

Pourquoi Redis à thread unique est-il rapide

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)

Structure des données et scénarios d'utilisation de Redis

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.

Stratégie d'expiration des données de Redis

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.

Set et setnx de Redis

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.

L'implémentation spécifique de LRU pour Redis :

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.

Comment Redis découvre-t-il les touches de raccourci ?

Collecte côté serveur : avant d'utiliser Redis, ajoutez une ligne de code pour les statistiques de données.
Capturez les paquets pour évaluation : Redis utilise le protocole TCP pour communiquer avec le client. Le protocole de communication utilise RESP, vous pouvez donc également intercepter les paquets pour analyse en écrivant votre propre programme pour surveiller le. port.
Au niveau de la couche proxy, collectez et signalez chaque requête Redis.
Redis est livré avec une requête de commande : la version Redis4.0.4 fournit des raccourcis clavier redis-cli pour trouver des touches de raccourci. (Si vous souhaitez utiliser la commande intégrée de Redis pour interroger, veuillez noter que vous devez d'abord définir la politique d'expulsion de mémoire sur allkeys-lfu ou volatile-lfu, sinon une erreur sera renvoyée. Entrez Redis et utilisez le jeu de configuration. maxmemory-policy allkeys-lfu )
Solution de clé de point d'accès Redis

Cache côté serveur : mettre en cache les données du point d'accès dans la mémoire du serveur. (Utilisez le mécanisme de notification de message fourni avec Redis pour garantir la cohérence des données entre Redis et la clé de point d'accès du serveur, et établissez un moniteur pour le client de clé de point d'accès. Lorsque la clé de point d'accès est mise à jour, le serveur mettez également à jour en conséquence.)

Clé de point d'accès de sauvegarde : c'est-à-dire clé de point d'accès + nombre aléatoire, distribuée de manière aléatoire à d'autres nœuds Redis. De cette façon, lors de l’accès aux clés de point d’accès, elles n’atteindront pas toutes une seule machine.
Comment résoudre le problème d'avalanche de cache Redis

Utiliser l'architecture haute disponibilité Redis : utilisez le cluster Redis pour garantir que le service Redis n'est pas disponible Crashera

Le temps de cache est incohérent, ajoutez une valeur aléatoire au délai d'expiration du cache pour éviter un échec collectif
Stratégie de limitation de rétrogradation actuelle : Il existe certains dépôts. Par exemple, le service de recommandation personnalisée n'est plus disponible. Il est remplacé par le service de recommandation de données chaudes
Comment faire. résoudre le problème de pénétration du cache Redis

Vérifiez sur l'interface

Enregistrer la valeur nulle (panne et verrouillage du cache, ou définir pour ne pas expire)
Interception du filtre Bloom : mappez d'abord toutes les clés de requête possibles au filtre Bloom Lors de l'interrogation, déterminez d'abord si la clé existe dans le filtre Bloom, puis continuez à l'exécuter vers le bas si. il existe. S'il n'existe pas, il reviendra directement. Le filtre Bloom stocke la valeur dans plusieurs bits de hachage. Si le filtre Bloom indique qu'un certain élément est présent, il peut être mal évalué. Si le filtre Bloom indique qu’un élément n’est pas là, alors il ne doit pas être là.
Mécanisme de persistance de Redis

Afin de garantir l'efficacité, Redis met en cache les données en mémoire, mais mettra périodiquement à jour les données. Écrivez sur le disque ou écrire des opérations de modification dans les fichiers d'enregistrement ajoutés pour garantir la persistance des données. Il existe deux stratégies de persistance pour Redis :

RDB : le formulaire d'instantané consiste à enregistrer directement les données en mémoire dans un fichier de dump, à les enregistrer régulièrement et à enregistrer la stratégie. Lorsque Redis doit être conservé, Redis créera un processus enfant et le processus enfant écrira les données dans un fichier RDB temporaire sur le disque. Lorsque le processus enfant termine l'écriture du fichier temporaire, remplacez le RDB d'origine.

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.

Transactions Redis

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.

Commandes liées aux transactions Redis

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

La différence entre Redis et memcached

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.

Plusieurs modes de cluster de Redis

Réplication maître-esclave
Mode Sentinel
mode cluster

Le mode Sentinel de Redis

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.

Rehachage de Redis

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.

Conditions d'extension de la table de hachage Redis

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