12 points clés souvent demandés lors des entretiens Redis (avec réponses)

Cet article vous présente un résumé de certaines questions souvent posées lors des entretiens sur Redis Il simule la façon dont l'intervieweur approfondit le sujet de Redis étape par étape et examine de manière approfondie la maîtrise de Redis par le candidat. pour mieux le comprendre. Tout le monde est utile.

Étude recommandée : "Dernières questions et réponses des entretiens Redis 2022"

12 points clés souvent demandés dans les entretiens Redis

Redis est un seuil qui ne peut être contourné dans l'entretien, tant qu'il est écrit dans le CV Si vous avez utilisé Redis, vous ne pourrez certainement pas y échapper.

Xiao Zhang :

Bonjour, intervieweur. Je suis ici pour une interview.

Intervieweur :

Bonjour, Xiao Zhang. J'ai lu votre CV et je maîtrise Redis, je vais donc simplement vous poser quelques questions liées à Redis. Tout d'abord, ma question est la suivante : Redis est-il monothread ou multithread ?

Xiao Zhang :

Les modèles de thread utilisés dans les différentes versions de Redis sont différents. Avant la version 4.0 de Redis, un modèle monothread était utilisé. Après la version 4.0, la prise en charge du multithread a été ajoutée.

Avant la version 4.0, même si nous disions que Redis était monothread, cela signifiait seulement que son thread d'E/S réseau et les opérations Set et Get étaient effectuées par un seul thread. Cependant, la persistance Redis et la synchronisation du cluster sont toujours effectuées à l'aide d'autres threads.

La prise en charge du multi-threading a été ajoutée après la version 4.0, principalement reflétée dans la fonction de suppression asynchrone des mégadonnées, telles que unlink key、flushdb async、flushall async etc.

Intervieweur :

La réponse est très bonne, Alors pourquoi Redis a-t-il choisi d'utiliser un seul thread avant 4.0 ? Et est-ce si rapide en utilisant un seul thread ?

Xiao Zhang :

Personnellement, je pense que le choix d'un seul thread est principalement dû à sa simplicité d'utilisation, à l'absence de compétition de verrouillage, à toutes les opérations peuvent être effectuées sans verrous et à l'absence de surcharge de performances et de temps causée par un blocage et changement de thread, mais en même temps, un seul thread ne peut pas exercer pleinement les performances d'un processeur multicœur.

Quant à la raison pour laquelle un seul thread est si rapide, je pense qu'il y a principalement les raisons suivantes :

• La plupart des opérations de Redis sont effectuées en mémoire. L'efficacité d'exécution en mémoire est très rapide et utilise des structures de données efficaces telles que le hachage. tables et sauter des tables.

• L'utilisation d'un seul thread évite la concurrence multi-thread, économise le temps et les performances causés par la commutation multi-thread et ne provoque pas de blocage.

• Utilise un mécanisme de multiplexage d'E/S pour gérer un grand nombre de requêtes Socket client, car il est basé sur un modèle d'E/S non bloquant, ce qui permet à Redis d'effectuer efficacement la communication réseau et les processus de lecture et d'écriture d'E/S Plus de blocage.

Intervieweur :

Bien, Comment Redis parvient-il à éviter toute perte de données ?

Xiao Zhang :

Les données Redis sont stockées dans la mémoire Afin de garantir que les données Redis ne sont pas perdues, les données doivent être stockées de la mémoire sur le disque afin que les données d'origine puissent être restaurées à partir du disque. après le redémarrage du serveur, c'est la persistance des données de Redis. Il existe trois façons de conserver les données Redis.

• Journal AOF (Append Only File, méthode d'ajout de fichier) : enregistrez toutes les commandes d'opération et ajoutez-les au fichier sous forme de texte.

• RDB Snapshot (Redis DataBase) : Écrivez les données de la mémoire à un certain moment sur le disque sous forme binaire.

• Méthode de persistance hybride : Redis 4.0 ajoute une nouvelle méthode de persistance hybride, intégrant les avantages de RDB et AOF.

Intervieweur :

Alors s'il vous plaît, parlez respectivement des principes de mise en œuvre de l'AOF et du RDB.

Xiao Zhang :

AOF utilise la journalisation post-écriture. Redis exécute d'abord la commande pour écrire les données dans la mémoire, puis enregistre le journal dans le fichier. Le journal AOF enregistre les commandes d'opération, pas les données réelles. Si la méthode AOF est utilisée pour la récupération après panne, l'intégralité du journal doit être exécutée.

RDB utilise une méthode d'instantané de mémoire. Il enregistre les données à un moment donné, pas les opérations. Par conséquent, lorsque vous utilisez la méthode RDB pour la récupération après erreur, il vous suffit de lire directement le fichier RDB dans la mémoire pour obtenir une récupération rapide. .

Intervieweur :

Vous venez de mentionner qu'AOF utilise la méthode du "journal de post-écriture", alors que MySQL que nous utilisons habituellement utilise la méthode du "journal de pré-écriture". Alors pourquoi Redis doit-il d'abord exécuter la commande, puis ensuite. écrire les données ? Qu'en est-il de l'écriture dans le journal ?

Xiao Zhang : J'ai commencé à transpirer sur mon front. Quelles sont les questions que vous avez posées ? . .

Eh bien, cela est principalement dû au fait que Redis n'effectue pas de vérification de syntaxe sur les commandes avant d'écrire le journal, il enregistre donc uniquement les commandes exécutées avec succès pour éviter d'enregistrer des commandes incorrectes, et l'écriture de journaux après l'exécution de la commande ne bloquera pas l'opération d'écriture en cours.

Intervieweur :

Alors quels sont les risques d'écrire un journal après  ?

Xiao Zhang :

Je...Je ne sais pas comment faire ça.

Intervieweur :

Eh bien, il y a deux risques principaux qui peuvent survenir lors de l'écriture de journaux :

• Les données peuvent être perdues : si Redis vient de terminer l'exécution de la commande et qu'une erreur se produit à ce moment-là, cette commande se produira. Il y a un risque de perte.

• Peut bloquer d'autres opérations : le journal AOF est en fait exécuté dans le thread principal, donc lorsque Redis écrit le fichier journal sur le disque, il bloquera toujours les opérations ultérieures et ne pourra pas être exécuté.

J'ai une autre question : Est-ce que RDB bloquera les threads lors de la prise d'instantanés ?

Xiao Zhang :

Redis fournit deux commandes pour générer des fichiers d'instantanés RDB, à savoir save et bgsave. La commande save est exécutée dans le thread principal et provoquera un blocage. La commande bgsave créera un processus enfant pour écrire les fichiers RDB, évitant ainsi de bloquer le thread principal. C'est également la configuration par défaut de Redis RDB.

Enquêteur :

RDB Les données peuvent-elles être modifiées lors de la prise d'un instantané ?

Xiao Zhang :

save est synchrone et bloquera les commandes client, mais il peut être modifié pendant bgsave.

Intervieweur :

Alors Comment Redis résout-il le problème de l'autorisation de modification des données lorsque bgsave prend un instantané ?

Xiao Zhang : (Pourquoi demandez-vous encore... Je ne sais pas comment !)

Euh, je ne suis pas sûr de cela...

Intervieweur :

Ici, nous utilisons principalement bgsave Implémenté par le sous-thread de code>, les opérations spécifiques sont les suivantes : <code>bgsave的子线程实现的，具体操作如下：

如果主线程执行读操作，则主线程和 bgsave 子进程互相不影响；

如果主线程执行写操作，则被修改的数据会复制一份副本，然后 bgsave

Si le thread principal effectue une opération de lecture, le thread principal et le sous-processus bgsave ne le feront pas

Si le thread principal effectue une opération d'écriture, ce sera Une copie des données modifiées sera effectuée, puis le sous-processus bgsave écrira les données de copie dans le RDB. fichier Au cours de ce processus, le thread principal peut toujours modifier directement les données d'origine.

Il convient de noter que la fréquence d'exécution de Redis sur RDB est très importante, car cela affectera l'intégrité des données d'instantané et la stabilité de Redis, donc après Redis 4.0, un mécanisme de persistance des données de

AOF et RDB un hybride a été ajouté

 : écrivez les données dans le fichier sous forme de RDB, puis stockez les commandes d'opération ultérieures dans le fichier au format AOF, ce qui garantit non seulement la vitesse de redémarrage de Redis, mais réduit également le risque de perte de données. perte.

Xiao Zhang :

J'ai appris, j'ai appris.

Intervieweur :

Alors pouvez-vous me dire comment Redis atteint la haute disponibilité ?

Xiao Zhang :

Il existe trois manières principales d'atteindre une haute disponibilité dans Redis : la réplication maître-esclave, le mode sentinelle et le cluster Redis.

Réplication maître-esclave

Synchronisez les données d'un serveur Redis précédent vers plusieurs serveurs Redis esclaves, c'est-à-dire un modèle maître-esclave. C'est le même principe que la réplication maître-esclave MySQL.

Mode Sentinelle

Lors de l'utilisation du service maître-esclave Redis, il y aura un problème, c'est-à-dire que lorsque le serveur maître-esclave Redis tombe en panne et tombe en panne, il doit être restauré manuellement dans l'ordre. pour résoudre ce problème, Redis a ajouté le mode Sentry (car le mode sentinelle peut surveiller les serveurs maître et esclave et fournir des fonctions automatiques de reprise après sinistre).

Redis Cluster (cluster)

Redis Cluster est un mode de fonctionnement distribué et décentralisé. C'est une solution de cluster Redis lancée en version Redis 3.0. Elle distribue les données sur différents serveurs. Cela réduit la dépendance du système à un. nœud maître unique, améliorant ainsi les performances de lecture et d'écriture du service Redis.

Intervieweur :

Utiliser le mode sentinelle pour assurer la copie des données sur les données et la surveillance sentinelle de la disponibilité. Une fois le maître défaillant, le nœud esclave est élu comme nœud maître. Cela a satisfait notre environnement de production. Oui,

Donc. pourquoi devez-vous toujours utiliser le mode cluster ?

Xiao Zhang :

Eh bien, le mode sentinelle est toujours un nœud maître-esclave. Dans le mode maître-esclave, nous pouvons étendre la capacité de lecture simultanée en ajoutant des nœuds salve, mais il n'y a aucun moyen d'étendre la capacité d'écriture. et capacité de stockage. La capacité de stockage ne peut que C'est la limite supérieure que le nœud maître peut transporter. Par conséquent, afin d’étendre les capacités d’écriture et de stockage, nous devons introduire le mode cluster.

Intervieweur :

Il y a tellement de nœuds maîtres dans le cluster, comment le cluster redis détermine-t-il quel nœud choisir lors du stockage ?

Xiao Zhang :

Cela devrait utiliser une sorte d'algorithme de hachage, mais je n'en suis pas sûr. . . 🎜🎜Intervieweur :🎜

D'accord, c'est tout pour l'interview d'aujourd'hui. Retournez en arrière et attendez notre notification d'interview.

Xiao Zhang :

D'accord, merci l'intervieweur, pouvez-vous me dire comment le cluster Redis implémente la sélection de nœuds ?

Intervieweur :

Redis Cluster utilise un algorithme de hachage cohérent pour implémenter la sélection de nœuds Quant à ce qu'est un algorithme de hachage cohérent, vous pouvez revenir en arrière et voir par vous-même.

Redis Cluster se divise en 16 384 emplacements de hachage. Chaque paire clé-valeur sera mappée à un emplacement de hachage en fonction de sa clé. Le processus d'exécution spécifique est divisé en deux Stride.

• Calculez une valeur de 16 bits basée sur la clé de la paire clé-valeur selon l'algorithme CRC16.

• Utilisez ensuite la valeur 16 bits pour modulo 16384 pour obtenir un module compris entre 0 et 16383. Chaque module représente un emplacement de hachage avec un numéro correspondant.

Chaque nœud Redis est responsable du traitement d'une partie des slots. Si vous ajoutez trois nœuds maîtres ABC, les slots dont chaque nœud est responsable sont les suivants :

De cette façon, la sélection des nœuds du cluster est réalisé.

Apprentissage recommandé : "Tutoriel vidéo Redis", "Dernières questions et réponses de l'entretien Redis 2022"

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!