Partage des questions d'entretien à haute fréquence Redis en 2023 (avec analyse des réponses)

Cet article résume et partage 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.

Analyse psychologique de l'intervieweur

Du point de vue de l'intervieweur, le but de cette question est de tester vos connaissances en mise en cache, ainsi que votre capacité à gérer des affaires et à améliorer l'architecture basée sur la mise en cache. Cette question vous permet évidemment de vous exprimer librement et vous donne la possibilité d'amener l'intervieweur vers les points de connaissances que vous connaissez le mieux, vous devez donc saisir cette opportunité autant que possible et donner une bonne impression à l'intervieweur. Si vous pouvez bien parler de cette question, vous pouvez communiquer en profondeur pendant plusieurs heures. S'il ne s'agit que d'une seule séance, vous pouvez la résoudre facilement. [Recommandation associée : Tutoriel vidéo Redis]

Mais ne discutez pas à mort tout de suite, le chat est trop superficiel, En gros, revenez en arrière et attendez la notification...

---

Par exemple, le façon suivante de répondre :

Beaucoup de gens diront que cette réponse est correcte ! C'est vrai, c'est vrai, mais on a toujours le sentiment que les opportunités qui vous sont offertes sont inutiles.

En ce moment, l'intervieweur pense quelque chose comme ceci :

• C'est relativement basique, je ne pense pas avoir une compréhension approfondie de Redis
• Je pense que la question reste en surface, je suppose que je sais comment le faire normalement, je n'y ai pas pensé. La question

• vous donne la possibilité de jouer librement. Si vous ne la comprenez pas, il semble que je doive encore le faire moi-même. quelques questions distribuées et persistantes d'abord pour voir à quel point vous êtes bon. Si cela ne fonctionne pas, restons-en là. Il y a encore beaucoup de gens qui quitteront le travail plus tard.

Si vous ne voulez pas résister aux dix-huit paumes de maîtrise du dragon de l'intervieweur, vous devez prendre l'initiative de susciter l'intérêt de l'intervieweur, prendre l'initiative d'améliorer votre propre structure (largeur et profondeur horizontales) et utiliser ce que vous savez. autant que possible Parlez davantage.

Par exemple, la manière suivante de répondre :

Résumé des questions d'entretien Redis

Ma compréhension est à peu près celle de cet intervieweur ! !

Hautes performances : un critère important pour des performances élevées est le temps de réponse rapide. Redis est basé sur le stockage en mémoire et offre une vitesse d'accès rapide au processeur. De plus, l'optimisation extrême de la structure des données, du modèle de thread interne et de la conception du modèle d'E/S réseau détermine que Redis est une base de données de stockage hautes performances. Le seul inconvénient est que la mémoire est relativement coûteuse et que les ressources sont généralement limitées. Par conséquent, l'architecture de cache pour les données très volumineuses doit être conçue de manière raisonnable. Nous ne stockons généralement pas de données trop volumineuses dans Redis, car cela entraînerait une diminution des performances de Redis.

Concurrence élevée : les indicateurs courants de concurrence élevée incluent le temps de réponse (temps de réponse), le débit (débit), le taux de requêtes par seconde (QPS) (requête par seconde) et le nombre d'utilisateurs simultanés, bien que Redis soit un processus unique. modèle de thread, Mais Redis est en effet un outil puissant dans les scénarios commerciaux à forte concurrence. Actuellement, le QPS de Redis peut atteindre 100 000 voire 1 million de niveaux.

Haute disponibilité : la haute disponibilité de Redis se reflète principalement dans la réplication maître-esclave, sentinelle (mode sentinelle) et Cluster (mode cluster)

Ma compréhension est à peu près celle de cet intervieweur ! !

Le thread unique de Redis fait référence à l'utilisation d'un seul thread pour exécuter des opérations de commande après la sortie de Redis6.

• Le modèle non bloquant de multiplexage d'E/S est utilisé pour gérer les connexions de socket client, ce qui peut considérablement optimiser la vitesse de réponse et l'efficacité du serveur Redis. La technologie de multiplexage d'E/S multicanal permet à un seul thread de gérer efficacement plusieurs connexions. . demandes pour minimiser la consommation de temps d’E/S du réseau.
• Basé sur le stockage mémoire, réduisant les E/S du disque et la vitesse de lecture rapide

• Redis a réalisé l'optimisation ultime de la structure de données interne, rendant la structure de données Redis très efficace. Et différentes méthodes de codage sont adoptées pour différentes quantités de données et contenus de stockage, ce qui implique la conversion de codage sous-jacente de Redis. Par exemple, les trois clés list, hash et zset utilisent le codage de liste de compression ziplist. Ziplist est une structure de données compacte lorsqu'une certaine valeur de clé contient moins d'éléments, elle sera d'abord stockée dans la ziplist. Si le nombre dépasse une certaine valeur, la ziplist sera convertie en une structure de stockage standard. Bien entendu, cette valeur peut être personnalisée dans redis.conf. De plus, la pré-allocation de mémoire de SDS, le hachage progressif dans Hash result Rehash et la séquence ZSet basée sur le stockage SkipList optimisent tous la structure des données et la rendent plus rapide.
• Redis utilise un seul thread lors de l'exécution des opérations de commande, sans tenir compte de la conception des verrous simultanés et de la consommation de changement de contexte du processeur causée par le multi-threading, donc l'exécution des commandes est plus rapide

Ma compréhension est à peu près la même dans le responsable de l'interview ! !

Redis dispose de 5 types de données de base : String, List, Hash, Set et ZSet. De plus, il existe trois types de données spéciaux : Bitmaps, Geospatial et HyperLogLog

 ;

Type de données	Description simple	scénario d'utilisation
String	string (string) est la structure de données la plus simple et la plus largement utilisée de Redis. Son intérieur est un tableau de caractères. String (string) est une chaîne dynamique qui permet des modifications ; son implémentation structurelle est similaire à ArrayList en Java (un tableau initial de taille 10 est construit par défaut). C'est l'idée d'allocation de mémoire redondante, également appelée pré). - L'allocation, cette idée peut réduire la consommation de performances causée par l'expansion. Lorsque la taille de la chaîne (chaîne) atteint le seuil d'expansion, la chaîne (chaîne) sera développée. Il existe trois situations principales pour l'expansion de la chaîne (chaîne) : 1. La longueur est inférieure à 1 Mo et l'expansion sera deux fois supérieure. taille d'origine ; longueur = longueur * 2 2. La longueur est supérieure à 1 Mo et augmente de 1 Mo après expansion ; longueur = longueur + 1 Mo 3. La longueur maximale de la chaîne est de 512 Mo	Cache, compteur, verrouillage distribué, etc. La liste de
List	Redis est équivalente à LinkedList en langage Java. Il s'agit d'une structure de données de liste doublement chaînée (mais cette structure est plus intelligemment conçue, qui sera présentée plus tard) et prend en charge le parcours séquentiel. Les opérations d'insertion et de suppression de la structure de liste chaînée sont rapides, avec une complexité temporelle de O(1), mais la requête est lente, avec une complexité temporelle de O(n). La liste (liste) de Redis n'est pas simple. LinkedList, mais quicklist - "quick list", quicklist est une liste bidirectionnelle composée de plusieurs ziplists (listes compressées)	liste chaînée, file d'attente asynchrone, liste chronologique des abonnés Weibo...
Hash	Redis hash (dictionnaire) est équivalent au HashMap dans le langage Java. Il s'agit d'un dictionnaire non ordonné distribué selon des valeurs de hachage. Les éléments internes sont stockés dans des paires clé-valeur. L'implémentation du hachage (dictionnaire) est également cohérente avec la structure de HashMap (JDK1.7) en Java. Sa structure de données est également une structure bidimensionnelle composée d'un tableau + d'une liste chaînée. Les éléments du nœud sont hachés sur le tableau If. une collision de hachage se produit, elle est utilisée. Les listes chaînées sont concaténées sur les nœuds du tableau. La valeur stockée dans le hachage (dictionnaire) dans Redis ne peut être que des valeurs de chaîne. De plus, l'expansion est différente de celle de HashMap en Java. HashMap en Java est réalisé en une seule fois lors de l'extension de sa capacité, tandis que Redis prend en compte le fait que son accès principal est un problème de performances monothread et, afin d'atteindre des performances élevées, il adopte une stratégie de remaniement progressif. Le rehachage progressif signifie qu'il n'est pas terminé une fois, mais est terminé plusieurs fois, donc l'ancienne structure de hachage doit être conservée. Par conséquent, le hachage (dictionnaire) dans Redis aura deux structures de hachage, l'ancienne et la nouvelle. est terminé, c'est l'ancien hachage. Ce n'est qu'après que toutes les valeurs ont été déplacées vers le nouveau hachage que le nouveau hachage remplacera complètement le hachage précédent en fonction.	Informations utilisateur, table de hachage...
Set	L'ensemble (set) de Redis est équivalent au HashSet dans le langage Java. Ses paires clé-valeur internes sont non ordonnées et uniques. Il implémente en interne un dictionnaire spécial où toutes les valeurs sont nulles. Une fois le dernier élément de la collection supprimé, la structure de données est automatiquement supprimée et la mémoire est récupérée.	Fonction de suppression de duplication, j'aime, je n'aime pas, amis communs...
ZSet	zset (ensemble ordonné) est la structure de données la plus fréquemment demandée dans Redis. C'est similaire à la combinaison de SortedSet et HashMap dans le langage Java. D'une part, il utilise set pour garantir l'unicité de la valeur interne, et d'autre part, il trie selon le score (poids) de la valeur. Cette fonction de tri est implémentée via Skip List. Une fois la dernière valeur d'élément de zset (ensemble ordonné) supprimée, la structure de données est automatiquement supprimée et la mémoire est recyclée.	Liste des fans, tri des performances des étudiants, classement du trafic, classement des clics...
Bitmaps	Les bitmaps sont appelés bitmaps, à proprement parler, ils ne sont pas un type de données. La couche inférieure des Bitmaps est un tableau d'octets de chaîne (valeur-clé). Nous pouvons utiliser get/set ordinaire pour obtenir et définir directement le contenu du bitmap, ou nous pouvons traiter le tableau d'octets comme un "tableau de bits" via les opérations bitmap getbit/setbit fournies par Redis. Chaque cellule du « tableau de bits » des Bitmaps ne peut stocker que 0 et 1. L'indice du tableau est appelé décalage dans les Bitmaps. Lorsque la clé n'existe pas lors de la définition des Bitmaps, une nouvelle chaîne sera automatiquement générée. Si le décalage défini dépasse la plage du contenu existant, le tableau de bits sera automatiquement étendu de zéro	Horloge des employés...
Geospatial	Geospatial est le module GEO de localisation géographique ajouté par Redis après la version 3.2	Les personnes à proximité de WeChat, commandent des "restaurants à proximité" en ligne...
HyperLogLog	HyperLogLog est un algorithme utilisé pour faire des statistiques de cardinalité, il fournit L'erreur standard du schéma de comptage de déduplication inexact (cette imprécision n'est pas très imprécise) est de 0,81 %. Cette plage d'erreur est autorisée pour les statistiques telles que UV. L'avantage d'HyperLogLog est que lorsque le nombre ou le volume des éléments d'entrée est très important, l'espace de stockage pour le calcul de cardinalité est fixe. Dans Redis, chaque clé HyperLogLog ne coûte que 12 Ko de mémoire et près de 2 ^ 64 bases différentes peuvent être calculées. Cependant, HyperLogLog ne peut compter que la taille de la cardinalité (c'est-à-dire la taille de l'ensemble de données et le nombre d'ensembles). Il ne peut pas stocker l'élément lui-même et ne peut pas stocker l'élément lui-même comme une collection d'ensembles, ce qui signifie qu'il ne peut pas le faire. éléments de retour.	Statistiques cardinales telles que UV, etc.

Ma compréhension de cela est à peu près celle de cet intervieweur ! !

La structure de données de Redis peut définir le délai d'expiration (TTL) de la clé via les secondes de clé EXPIRE. Nous avons également l'habitude de penser que la clé Redis sera automatiquement supprimée à son expiration. Évidemment, cette idée n'est pas correcte. La conception de Redis prend en compte des facteurs complets tels que les performances/mémoire et conçoit un ensemble de stratégies d'expiration.

• Suppression active (suppression paresseuse)
• Suppression passive (stratégie périodique)

Suppression active (suppression paresseuse) signifie que lors de l'accès à la clé, il vérifie d'abord si la clé a expiré, et si elle expire, elle est activement supprimé.

La suppression passive (stratégie périodique) fait référence au serveur Redis testant régulièrement et aléatoirement le délai d'expiration de la clé si elle expire, elle sera supprimée passivement. L'existence d'une suppression passive est essentielle car certaines clés ont expiré et ne seront jamais accessibles. Si elles reposent sur une suppression active, elles occuperont la mémoire de manière permanente.

Afin de garantir des services performants, Redis supprime passivement les clés expirées et adopte une stratégie/algorithme probabiliste glouton. Par défaut, il analyse toutes les 10 secondes. La stratégie spécifique est la suivante :

• 1. dictionnaire (le délai d'expiration est défini. Sélectionnez au hasard 20 clés dans le jeu de clés) et vérifiez si elles sont expirées

• 2 Supprimez les clés expirées

• 3 Si le nombre de clés expirées supprimées est supérieur à 25%, répétez l'étape 1

De plus, lors de la conception de l'architecture de cache Redis, les développeurs doivent faire attention à éviter autant que possible (interdit) de définir un grand nombre de clés sur le même délai d'expiration, car combiné à une suppression passive, cela peut être On voit que lorsque Redis supprime passivement les clés expirées, le service sera temporairement indisponible. Si un grand nombre de clés expirent en même temps, les trois étapes de suppression passive des clés seront répétées plusieurs fois, ce qui entraînera le redémarrage de Redis. service à geler. Cette situation est inacceptable dans les grands projets de circulation.

Donc, afin d'éviter cette situation, vous devez définir certaines clés dont le délai d'expiration autorisé n'a pas besoin d'être très précis sur un délai d'expiration plus aléatoire, afin que le temps de décalage puisse être réduit.

C'est ma compréhension de l'intervieweur ! !

Dans les scénarios distribués, nos solutions de verrouillage distribué courantes incluent (si vous savez comment le faire, vous pouvez apporter les deux autres ici, sinon, ne vous trompez pas !) :

• Verrous distribués implémentés en fonction sur le mécanisme de verrouillage de la base de données

• Verrous distribués implémentés sur la base de Zookeeper

• Verrous distribués implémentés sur la base de Redis

La solution permettant à Redis d'implémenter des verrous distribués est la suivante.

Si Redis est dans un environnement autonome, Nous pouvons implémenter des verrous distribués via les instructions atomiques fournies par Redis

définir la valeur de la clé [EX secondes] [PX millisecondes] [NX|XX]

Afin d'éviter Un ajout Le verrou a été supprimé par B. Lors du verrouillage, la balise de verrouillage du client peut être transmise. Le déverrouillage n'est autorisé que lorsque la balise transmise par le client est la même que la balise de verrouillage. Cependant, Redis ne fournit pas une telle fonction. Nous ne pouvons transmettre que le script Lua à gérer, car le script Lua peut assurer l'exécution atomique de plusieurs instructions. Enfin, nous devons considérer le problème du délai d'expiration du verrouillage. Si le client ne libère jamais le verrou, cela ne fonctionnera certainement pas. Par conséquent, le verrou ne peut que garantir qu'il ne sera pas déverrouillé par d'autres clients dans le délai d'expiration spécifié. être automatiquement libéré après le délai d'attente.Ce genre de situation est difficile.Nous pouvons l'optimiser comme ceci :

• Essayez de ne pas exécuter de longues tâches dans le verrouillage distribué Redis et exécutez le code dans l'intervalle de verrouillage aussi étroit que possible, tout comme l'optimisation synchronisée dans un seul verrou JVM, nous pouvons envisager d'optimiser la plage de verrouillage

• Faire davantage de tests de stress et de tests de simulation en ligne de scénarios réels pour estimer un délai d'expiration de verrouillage approprié

• Faire du bon travail de récupération de données après le problème de la tâche de délai d'expiration du verrouillage distribué Redis se produit. Préparation des moyens

Si c'est dans un environnement distribué, ajoutera un nouveau problème. Par exemple, dans un environnement sentinelle + un maître et plusieurs esclaves. le client peut demander un verrou sur le nœud maître, mais la synchronisation n'est pas terminée et le nœud maître est en panne et le verrou sur le nœud maître nouvellement élu n'est pas valide.

La gestion de cette situation doit être envisagée de cette manière. Tout d'abord, la synchronisation directe maître-esclave Redis ne peut en aucun cas résoudre le problème de la perte de données. Nous envisageons donc de remplacer l'application de verrouillage Redis par plusieurs applications de verrouillage Redis autonomes. Seules la plupart des applications réussissent. Cette idée est RedLock.

RedLock utilise plusieurs instances Redis. Il n'y a pas de relation maître-esclave entre chaque instance et elles sont indépendantes les unes des autres. Lors du verrouillage, le client envoie des instructions de verrouillage à tous les nœuds. Si plus de la moitié des nœuds sont définis avec succès, le client envoie des instructions de verrouillage à tous les nœuds. le verrouillage est réussi. Lors de la libération du verrou, vous devez envoyer des instructions del à tous les nœuds pour libérer le verrou.

Bien que Red Lock résolve le problème de la synchronisation maître-esclave, il apporte de nouveaux problèmes complexes :

• Le premier problème est la dérive de l'horloge
• Le deuxième problème est que le client demande avec succès un verrou à différents moments à partir de différents serveurs Redis

Donc, dans RedLock, il est nécessaire de calculer la durée effective minimale du verrou appliqué. Supposons que le client demande un verrou avec succès, que l'heure à laquelle la première clé est définie avec succès est TF, l'heure à laquelle la dernière clé est définie avec succès est TL, le délai d'expiration du verrouillage est TTL et la différence d'horloge entre les différents processus est CLOCK_DIFF, alors la validité minimale du verrou La durée est :

TIME = TTL - (TF- TL) - CLOCK_DIFF

Utiliser Redis pour implémenter des verrous distribués, ce qui est indissociable des problèmes d'indisponibilité tels que les temps d'arrêt du serveur La même chose est vraie. pour RedLock ici, même s'il y en a plusieurs. Lorsque le serveur demande un verrou, nous devons également réfléchir à ce qu'il faut faire après la panne du serveur. La recommandation officielle est d'utiliser la persistance AOF.

Cependant, la persistance AOF ne peut être redémarrée et restaurée que pour les instructions d'ARRÊT normales. Cependant, en cas de panne de courant, les données de verrouillage de la dernière persistance jusqu'à la panne de courant peuvent être perdues. cela peut se produire. Le cas où la sémantique du verrouillage distribué est incorrecte. Par conséquent, afin d'éviter cette situation, la recommandation officielle est qu'après le redémarrage du service Redis, le service Redis sera indisponible dans un délai maximal de durée de vie du client (aucun service d'application de verrouillage n'est fourni). Cela peut effectivement résoudre le problème, mais cela). Il est évident que cela affectera définitivement les performances du serveur Redis, et lorsque cela arrivera à la plupart des nœuds, le système deviendra globalement indisponible.

C'est ma compréhension de l'intervieweur ! !

Redis est très rapide. Cela s'explique en grande partie par le fait que les données Redis sont stockées en mémoire, lorsque le serveur tombe en panne ou est mis hors tension, toutes les données sont perdues, donc Redis le fournit. Deux mécanismes sont utilisés pour garantir que toutes les données Redis ne seront pas perdues en raison de pannes. Ce mécanisme est appelé mécanisme de persistance de Redis.

Redis dispose de deux mécanismes de persistance :

• instantané de mémoire RDB (Redis Data Base)
• journal incrémental AOF (Append Only File)

RDB (Redis DataBase) fait référence à l'instantané de l'ensemble de données spécifié en mémoire est écrit sur le disque dans un intervalle de temps. RDB est conservé sous la forme d'un instantané de mémoire (forme de sérialisation binaire des données de mémoire). Chaque fois, un instantané est généré à partir de Redis pour sauvegarder complètement les données.

Avantages :

• Stockage compact, économisant de l'espace mémoire
• La vitesse de récupération est très rapide

• Convient aux scénarios de sauvegarde complète et de copie complète, souvent utilisé pour la reprise après sinistre (par rapport aux exigences d'intégrité et de cohérence des données) Inférieur occasions)

Inconvénients :

• Il est facile de perdre des données, et il est facile de perdre les données modifiées dans le serveur Redis entre deux instantanés.
• RDB utilise le sous-processus fork pour sauvegarder entièrement l'instantané de mémoire. Il s'agit d'une opération lourde et le coût d'une exécution fréquente est élevé.

• Les processus enfants de Fork, bien qu'ils partagent la mémoire, si la mémoire est modifiée lors de la sauvegarde, elle peut s'étendre jusqu'à un maximum de 2 fois sa taille.

Les règles déclenchées par RDB sont divisées en deux catégories, à savoir le déclenchement manuel et le déclenchement automatique :

Déclenchement automatique :

• Configurer les règles de déclenchement

• déclencheur d'arrêt

• déclencheur de rinçage

Déclencheur manuel :

• save

• bgsave

AOF (Append Only File) enregistre toutes les instructions (opérations d'écriture) qui modifient la mémoire dans un fichier journal séparé et exécute le fichier AOF lors du redémarrage de la commande Redis pour restaurer les données . AOF peut résoudre le problème de la persistance des données en temps réel et constitue la solution de persistance principale dans le mécanisme de persistance Redis actuel (nous parlerons plus tard de la persistance hybride après la version 4.0).

Avantages :

• La sauvegarde des données est plus complète, la probabilité de perte de données est plus faible, adaptée aux scénarios avec des exigences élevées en matière d'intégrité des données
• Le fichier journal est lisible, AOF est plus exploitable et le fichier journal peut être Réparation opérée

Inconvénients :

• Les enregistrements des journaux AOF deviennent progressivement plus volumineux lors d'un fonctionnement à long terme et la récupération prend beaucoup de temps. Les journaux AOF doivent être allégés régulièrement (détaillés plus tard)
• La vitesse de restauration de la sauvegarde est. relativement lent

• Des opérations d'écriture synchrones fréquentes entraîneront une pression sur les performances

Le journal AOF existe sous la forme d'un fichier Lorsque le programme écrit dans le fichier journal AOF, le contenu est en fait écrit dans une mémoire allouée par le noyau. pour le descripteur de fichier Dans le tampon, le noyau videra ensuite de manière asynchrone les données du tampon sur le disque. Si le serveur tombe en panne avant que les données du tampon n'aient le temps d'être vidées sur le disque, les données seront perdues.

Donc Redis appelle fsync(int fid) fourni par la glibc du système d'exploitation Linux pour forcer le contenu du fichier spécifié du tampon du noyau vers le disque afin de garantir que les données du tampon ne seront pas perdues. Cependant, il s'agit d'une opération d'E/S, qui est très lente par rapport aux performances de Redis, elle ne peut donc pas être exécutée fréquemment.

Il existe trois configurations de tampon de vidage dans le fichier de configuration Redis :

appendfsync toujours

Chaque opération d'écriture Redis est écrite dans le journal AOF. En théorie, le système d'exploitation Linux ne peut pas gérer cette configuration car la simultanéité de Redis dépasse de loin la fréquence de rafraîchissement maximale fournie par le système d'exploitation Linux, même s'il y a relativement peu d'opérations d'écriture Redis. . , cette configuration est également très gourmande en performances, car elle implique des opérations d'E/S, donc cette configuration n'utilise fondamentalement pas

appendfsync everysec

actualise les données dans le tampon dans le fichier AOF toutes les secondes, dans ce fichier de configuration Redis. La stratégie par défaut est compatible avec un compromis entre performances et intégrité des données. Avec cette configuration, théoriquement les données sont perdues en une seconde environ

appendfsync no

Le processus Redis ne rafraîchira pas activement le tampon. Les données sont stockées dans le AOF, mais est directement transmis au système d'exploitation pour jugement. Cette opération n'est pas recommandée et le risque de perte de données est très élevé.

Quand j'ai mentionné les lacunes d'AOF plus tôt, j'ai dit qu'AOF est une forme d'ajout de journal pour stocker les instructions d'écriture Redis. Cela entraînera un grand nombre de stockage d'instructions redondantes, ce qui rendra le fichier journal AOF très volumineux. ne prend que de la mémoire, mais cela entraînera également une récupération très lente, donc Redis fournit un mécanisme de réécriture pour résoudre ce problème. Une fois que le mécanisme de persistance AOF de Redis a effectué la réécriture, il enregistre uniquement le jeu d'instructions minimum pour restaurer les données. Si nous voulons le déclencher manuellement, nous pouvons utiliser les instructions suivantes

bgrewriteaof

La réécriture après Redis 4.0 utilise des instantanés RDB et des instructions AOF ajoutées. de cette façon, l'en-tête du fichier AOF est la forme binaire des données de l'instantané RDB et la queue est l'instruction de l'opération d'écriture qui s'est produite après la génération de l'instantané.

Étant donné que la réécriture des fichiers AOF aura un certain impact sur les performances de Redis, la réécriture automatique ne peut pas être effectuée de manière fortuite :

. auto-aof-rewrite-percentage 100 : fait référence au moment où la mémoire du fichier atteint deux fois la mémoire d'origine

auto-aof-rewrite-min-size 64 Mo : fait référence à la taille de mémoire minimale pour la réécriture du fichier

De plus, la plupart des scénarios d'utilisation après Redis 4.0 n'utiliseront pas RDB ou AOF seuls comme mécanisme de persistance, mais prendront en compte les avantages des deux.

Enfin, pour résumer les deux, lequel est le meilleur ?

• Il est recommandé d'activer les deux
• Si les données ne sont pas sensibles, vous pouvez choisir d'utiliser RDB seul

• Il n'est pas recommandé d'utiliser AOF seul car des bugs peuvent survenir
• Si vous faites juste du pur la mise en cache de la mémoire, vous ne pouvez utiliser ni l'un ni l'autre

C'est ma compréhension de l'intervieweur ! !

Redis est une base de données clé-valeur basée sur le stockage en mémoire. Nous savons que même si la mémoire est rapide, l'espace est petit lorsque la mémoire physique atteint la limite supérieure, le système fonctionnera très lentement, nous définirons donc le maximum. mémoire de Redis. Quand la mémoire Redis Le recyclage de la mémoire sera déclenché lorsque le seuil défini est atteint Redis propose de nombreuses stratégies d'élimination de la mémoire :

• noeviction : Lorsque la limite de mémoire est atteinte et que le client tente d'exécuter une commande pouvant provoquer. plus de mémoire à utiliser, une erreur est renvoyée. En termes simples, les opérations de lecture sont toujours autorisées, mais l'écriture de nouvelles données n'est pas autorisée, les requêtes del (suppression) le sont .
• allkeys-lru : Élimine de toutes les clés via l'algorithme lru (Least Récemment utilisé - Le moins récemment utilisé)

• allkeys-random : Élimine aléatoirement de toutes les clés
• volatile- lru : De toutes les clés avec un délai d'expiration défini, elles sont éliminées via l'algorithme lru (Least Récemment utilisé - Le moins récemment utilisé). Cela garantit que les données qui n'ont pas de délai d'expiration et doivent être conservées ne seront pas sélectionnées pour l'élimination

• . volatile-random : Élimine aléatoirement de toutes les clés avec un délai d'expiration défini
• volatile-ttl : De toutes les clés avec un délai d'expiration défini, comparez la valeur TTL du délai d'expiration restant de la clé, TTL Plus la taille est petite, la première il sera éliminé

• volatile-lfu : Utilisez l'algorithme d'élimination LFU pour les clés avec délai d'expiration
• allkeys-lfu : Utilisez l'algorithme d'élimination LFU pour toutes les clés

Il existe deux de ces stratégies. L'un des algorithmes les plus importants est LRU, qui élimine la clé la moins récemment utilisée. Cependant, Redis utilise un algorithme LRU approximatif, qui n'est pas complètement précis pour éliminer les clés les moins fréquemment utilisées récemment, mais la précision globale peut être garantie.

L'algorithme LRU approximatif est très simple. Dans l'objet clé Redis, 24 bits sont ajoutés pour stocker l'horodatage système du dernier accès Lorsque le client envoie une requête liée à l'écriture de clé au serveur Redis, il s'avère que le la mémoire atteint la mémoire maximale. Cette suppression paresseuse est déclenchée lors d'un échantillonnage aléatoire dans la clé), comparez le dernier horodatage d'accès enregistré dans l'objet clé et éliminez la clé la plus ancienne parmi les cinq clés, si la mémoire n'est toujours pas suffisante, continuez à répéter cette opération ; étape.

Dans Redis 3.0, lorsque maxmemory_samples est défini sur 10, l'algorithme LRU approximatif de Redis est très proche du véritable algorithme LRU, mais il est évident que définir maxmemory_samples sur 10 consomme plus de temps de calcul CPU que définir maxmemory_samples sur 5 en raison des exemples de données échantillonnés à chaque fois. si cela augmente, le temps de calcul augmentera également.

L'algorithme LRU de Redis3.0 est plus précis que l'algorithme LRU de Redis2.8, car Redis3.0 ajoute un pool d'élimination de la même taille que maxmemory_samples Chaque fois qu'une clé est éliminée, elle attend d'abord de l'être. éliminées dans le pool d'élimination Les clés sont comparées, et la clé la plus ancienne est finalement éliminée. En fait, les clés sélectionnées pour l'élimination sont rassemblées et comparées à nouveau, et la clé la plus ancienne est éliminée.

LRU présente un défaut évident : il ne peut pas représenter correctement la popularité d'une clé. Si une clé n'a jamais été accédée et a été accédée par l'utilisateur juste avant l'élimination de la mémoire, cela sera pris en compte dans l'algorithme LRU. . LFU (Least Frequency Used) est un algorithme d'élimination introduit dans Redis 4.0. Il élimine les clés en comparant la fréquence d'accès des clés. Le point clé est Fréquemment utilisé.

La différence entre LRU et LFU :

• LRU -> Récemment utilisé, comparé en fonction de l'heure de l'accès le plus récent
• LFU -> Fréquemment utilisé, comparé en fonction de la fréquence d'accès de la clé

En mode LFU, le champ lru de 24 bits de l'en-tête de l'objet Redis est divisé en deux segments pour le stockage. Les 16 bits supérieurs stockent ldt (Last Decrement Time) et les 8 bits inférieurs stockent logc (Compteur logistique). Les 16 bits supérieurs sont utilisés pour enregistrer la dernière fois que le compteur a diminué. Puisqu'il n'y a que 8 bits, stocke l'horodatage des minutes Unix modulo 2^16 La valeur maximale que 16 bits peuvent représenter est 65535 (65535/24/60. ≈45,5), soit environ 45,5 jours, reviendra en arrière (revenir en arrière signifie que la valeur modulo repart de 0).

Les 8 bits inférieurs sont utilisés pour enregistrer la fréquence d'accès. La valeur maximale que 8 bits peuvent représenter est de 255. Logc ne peut certainement pas enregistrer le nombre réel de temps d'accès Rediskey. En fait, cela peut être vu à partir du nom qu'il stocke. le logarithme du nombre de fois d'accès. Chaque nouvel ajout La valeur initiale du logc de la clé est 5 (LFU_INITI_VAL), ce qui garantit que les valeurs nouvellement ajoutées ne seront pas sélectionnées et éliminées en premier, le logc sera mis à jour à chaque fois que la clé est ; accessible ; de plus, logc se décomposera avec le temps.

Logistic Counter va non seulement croître, mais aussi décliner. Les règles de croissance et de décroissance peuvent également être configurées via redis.conf.

• lfu-log-factor est utilisé pour ajuster le taux de croissance du compteur logistique. Plus la valeur lfu-log-factor est élevée, plus le taux de croissance du compteur logistique est lent.
• lfu-decay-time est utilisé pour ajuster la vitesse de décroissance du compteur logistique. La valeur par défaut est 1. Plus la valeur lfu-decay-time est grande, plus la décroissance est lente.

C'est ma compréhension de l'intervieweur ! !

Panne du cache :

signifie qu'une clé de hotspot consultée très fréquemment se trouve dans une situation d'accès centralisé à haute concurrence. Lorsque la clé devient invalide, un grand nombre de requêtes pénètrent dans le cache et demandent directement la clé. la base de données passe directement par Redis.

Solution :

• Si les données mises en cache sont relativement fixes, vous pouvez essayer de configurer les données du point d'accès pour qu'elles n'expirent jamais.
• Si les données mises en cache ne sont pas mises à jour fréquemment et que l'ensemble du processus d'actualisation du cache prend moins de temps, vous pouvez utiliser des verrous mutex distribués basés sur des middleware distribués tels que Redis et zookeeper, ou des verrous mutex locaux pour garantir que seul un petit nombre de requêtes peuvent demandez la base de données et reconstruisez le cache, et les threads restants peuvent accéder au nouveau cache une fois le verrou libéré.

• Si les données mises en cache sont fréquemment mises à jour ou si le processus d'actualisation du cache prend beaucoup de temps, vous pouvez utiliser le thread de synchronisation pour reconstruire activement le cache avant l'expiration du cache ou retarder le délai d'expiration du cache pour garantir que toutes les demandes Le cache correspondant est toujours accessible.

Pénétration du cache :

fait référence à la demande de données qui n'existent pas dans le cache ou la base de données. Cette situation est généralement causée par des pirates informatiques. Si aucune défense n'est prise, cela peut facilement conduire à la destruction de la base de données. la demande. Par exemple, si un pirate informatique utilise un identifiant négatif pour interroger l'une de vos tables, notre identifiant n'est généralement pas défini sur un nombre négatif.

Solution :

• Si la base de données n'est pas interrogée, définissez une valeur nulle dans le cache Cette méthode ne peut pas résoudre la situation d'utilisation de différentes demandes d'identification négatives.
• Utilisez le filtre Bloom pour mapper toutes les données de la base de données au filtre Bloom Avant de faire la demande, utilisez le filtre Bloom pour déterminer si elle existe. S'il n'existe pas, renvoyez-le simplement directement.

---

Avalanche de cache :

Une avalanche de cache se produit lorsqu'un grand nombre de caches échouent en même temps, ce qui entraînera un crash instantané de la base de données (scénario de forte concurrence), et dans ce cas, si le cache n'est pas restaurée, la base de données sera inutile ou continuera à être vaincue.

Solution :

• Conception de l'architecture du cache : conception de Redis à haute disponibilité, maître-esclave + sentinelle, cluster de cluster Redis
• Serveur de projet : utiliser le cache local et le traitement de dégradation des services pour minimiser les requêtes vers MySQL

• Méthodes d'exploitation et de maintenance : surveiller régulièrement Redis Cluster, un mécanisme de sauvegarde persistant, et les données mises en cache peuvent être restaurées à temps en cas d'avalanche

Ayant presque répondu à cette question, le visage de l'intervieweur a montré un sourire perdu depuis longtemps, et nous n'avons d'autre choix que de prenez cette astuce, cette fois L'interview est là.

Bien sûr, ce point de connaissance ne peut pas être expliqué clairement en quelques phrases, je vous suggère donc de lire cet article et vous pourrez facilement le conserver

"Redis Distributed - La réplication maître-esclave, Sentinel et le clustering sont minutieusement compris 》

Cet article est reproduit à partir de : https://juejin.cn/post/7019088999792934926

Auteur : Li Zi捌

Pour plus de connaissances liées à la programmation, veuillez visiter : Introduction à 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!