Le partage de questions d'entretien Redis à haute fréquence vous aidera à maîtriser les points de connaissances fondamentaux !

Cet article compile et partage avec vous quelques questions d'entretien Redis à haute fréquence et vous présente les principaux points de connaissance de Redis, impliquant la structure des données, le modèle de mémoire, le modèle IO, le RDB persistant, etc. J'espère qu'il vous sera utile !

Pourquoi Redis est-il si rapide ?

Beaucoup de gens savent seulement qu'il s'agit d'une base de données en mémoire K/V NoSQl, d'un seul thread... C'est parce qu'ils ne comprennent pas complètement Redis et ne peuvent pas continuer à poser plus de questions.

Cette question est une compréhension de base. Nous pouvons l'implémenter à partir des structures de données sous-jacentes de différents types de données dans Redis, entièrement basées sur la mémoire, le modèle de réseau de multiplexage IO, le modèle de thread, le rehash progressif...

À quelle vitesse est-ce ?

Nous pouvons d'abord parler de sa rapidité. Selon les données officielles, le QPS de Redis peut atteindre environ 100 000 (requêtes par seconde). Ceux qui sont intéressés peuvent se référer au programme de référence officiel « Quelle est la vitesse de Redis ? 》, adresse : redis.io/topics/benc…

L'axe horizontal est le nombre de connexions, et l'axe vertical est le QPS.

Cette image reflète un ordre de grandeur. Grâce à la quantification, elle donne à l'intervieweur le sentiment que vous avez lu les documents officiels et que vous êtes très rigoureux.

Implémenté basé sur la mémoire

Redis est une base de données basée sur la mémoire Par rapport aux bases de données sur disque, elle bat complètement la vitesse des disques.

Les opérations de lecture et d’écriture sont effectuées sur la mémoire, comparons respectivement les différences entre les opérations sur la mémoire et les opérations sur le disque.

Appel de disque

Fonctionnement de la mémoire

La mémoire est directement contrôlée par le CPU, qui est le contrôleur de mémoire intégré à l'intérieur du CPU, de sorte que la mémoire est directement connectée au CPU et bénéficie de la bande passante optimale pour la communication avec le CPU.

Enfin, une image est utilisée pour quantifier les différents retards du système (une partie des données est citée par Brendan Gregg)

Structure de données efficace

Quand j'apprenais MySQL, je savais que les données B+ Tree La structure a été utilisée afin d'améliorer la vitesse de récupération. La vitesse de Redis doit donc également être liée à la structure des données.

Redis a un total de 5 types de données, String、List、Hash、Set、SortedSet.

Différents types de données sont pris en charge par une ou plusieurs structures de données en bas, afin d'atteindre une vitesse plus rapide.

Message de frère Ma : Nous pouvons expliquer séparément les avantages de la structure de données sous-jacente de chaque type de données. De nombreuses personnes ne connaissent que le type de données, et indiquer la structure de données sous-jacente peut faire briller les yeux des gens.

SDS Avantage simple de la chaîne dynamique

• Dans SDS, len enregistre la longueur de cette chaîne et la complexité temporelle O(1) est utilisée pour interroger les informations sur la longueur de la chaîne.

• Pré-allocation d'espace : une fois le SDS modifié, le programme allouera non seulement l'espace nécessaire requis pour le SDS, mais allouera également de l'espace supplémentaire inutilisé.

• Libération d'espace paresseuse : lors du raccourcissement du SDS, le programme ne récupérera pas l'espace mémoire excédentaire, mais utilisera le champ libre pour enregistrer le nombre d'octets et ne les libérera pas si une opération d'ajout est nécessaire ultérieurement. utilisez-le directement. L’espace libre inutilisé réduit l’allocation de mémoire.

zipList Compressed List

Compressed List est l'une des implémentations sous-jacentes des trois types de données List, hash et Sorted Set.

Lorsqu'une liste ne contient qu'une petite quantité de données et que chaque élément de la liste est soit une petite valeur entière, soit une chaîne relativement courte, Redis utilisera une liste compressée comme implémentation sous-jacente de la clé de liste.

De cette façon, la mémoire est compacte et économise de la mémoire.

quicklist

Les versions ultérieures ont transformé la structure des données de la liste, en utilisant quicklist au lieu de ziplist et linkedlist.

quicklist est un mélange de liste zip et de liste liée. Il divise la liste liée en segments. Chaque segment utilise une liste zip pour un stockage compact, et plusieurs listes zip sont connectées entre elles à l'aide de pointeurs bidirectionnels.

skipList Skip List

La fonction de tri du type d'ensemble trié est implémentée via la structure de données "skip list".

La liste de sauts est une structure de données ordonnée qui maintient plusieurs pointeurs vers d'autres nœuds dans chaque nœud pour atteindre l'objectif d'accéder rapidement aux nœuds.

La liste de saut ajoute des index multi-niveaux sur la base de la liste chaînée. Grâce à plusieurs sauts dans la position de l'index, les données peuvent être rapidement positionnées, comme le montre la figure ci-dessous :

Tableau d'entiers (intset)

Lorsqu'un ensemble ne contient que des éléments de valeur entière et que le nombre d'éléments dans cet ensemble n'est pas grand, Redis utilisera un ensemble entier comme implémentation sous-jacente de la clé d'ensemble pour économiser de la mémoire.

Modèle monothread

Message de frère Ma : Nous devons noter que le monothread de Redis fait référence à l'IO réseau de Redis (l'IO réseau utilise le multi-threading après la version 6.x) et à la valeur-clé La lecture et l'écriture des instructions de paire sont exécutées par un thread. La persistance Redis, la synchronisation des données du cluster, la suppression asynchrone, etc. sont toutes exécutées par d'autres threads.

Ne dites jamais que Redis n'a qu'un seul thread.

Le thread unique fait référence à l'exécution d'instructions de lecture et d'écriture de paires clé-valeur Redis dans un seul thread.

Parlons d'abord de la réponse officielle, qui donne aux gens le sentiment d'être suffisamment rigoureux, au lieu de simplement réciter certains blogs en fonction de ce que disent les autres.

Réponse officielle : Étant donné que Redis est une opération basée sur la mémoire, le processeur n'est pas le goulot d'étranglement de Redis. Le goulot d'étranglement de Redis est probablement la taille de la mémoire de la machine ou la bande passante du réseau. Étant donné que le monothreading est facile à mettre en œuvre et que le processeur ne deviendra pas un goulot d'étranglement, il est logique d'adopter une solution monothread. Adresse d'origine : redis.io/topics/faq.

Pourquoi ne pas utiliser l'exécution multithread pour utiliser pleinement le CPU ?

Avant d'exécuter chaque tâche, le processeur doit savoir où la tâche est chargée et commencée à s'exécuter. Autrement dit, le système a besoin d'aide pour configurer au préalable les registres du processeur et le compteur de programme, ce que l'on appelle le contexte du processeur.

Lors d'un changement de contexte, nous devons effectuer une série de travaux, ce qui est une opération très gourmande en ressources.

L'introduction du développement multithread nécessite l'utilisation de primitives de synchronisation pour protéger la lecture et l'écriture simultanées des ressources partagées, augmentant ainsi la complexité du code et la difficulté de débogage.

Quels sont les avantages du fil unique ?

Il n'y aura aucune consommation de performances causée par la création de threads ;
1. Évitez la consommation de processeur causée par le changement de contexte, et il n'y a pas de surcharge de commutation multi-thread ;
2. Évitez les problèmes de concurrence entre les threads, tels que l'ajout de verrous, la libération ; les verrous et les verrous morts, etc., il n'est pas nécessaire de prendre en compte divers problèmes de verrouillage.
3. Le code est plus clair et la logique de traitement est simple.

Modèle de multiplexage d'E/S

Redis utilise la technologie de multiplexage d'E/S pour traiter les connexions simultanément. Utilisation d'epoll + un framework d'événements simple implémenté par moi-même.

La lecture, l'écriture, la fermeture et la connexion dans epoll sont tous convertis en événements, puis utilisez la fonction de multiplexage d'epoll pour ne jamais perdre de temps sur les IO.

Le thread Redis ne se bloquera pas sur un socket d'écoute ou connecté spécifique, c'est-à-dire qu'il ne bloquera pas sur le traitement d'une demande client spécifique. De ce fait, Redis peut se connecter à plusieurs clients en même temps et traiter les demandes, améliorant ainsi la simultanéité.

Dictionnaire de hachage global Redis

Redis dans son ensemble est une table de hachage pour enregistrer toutes les paires clé-valeur, quels que soient les 5 types de données. Une table de hachage est essentiellement un tableau et chaque élément est appelé un compartiment de hachage. Quel que soit le type de données, l'entrée dans chaque compartiment contient un pointeur vers la valeur spécifique réelle.

La complexité temporelle de la table de hachage est O(1). Il vous suffit de calculer la valeur de hachage de chaque clé pour connaître l'emplacement du bucket de hachage correspondant. Localisez l'entrée dans le bucket pour trouver les données correspondantes. . C'est aussi l'une des raisons pour lesquelles Redis est rapide.

Redis utilise des objets (redisObject) pour représenter les valeurs clés dans la base de données Lorsque nous créons une paire clé-valeur dans Redis, au moins deux objets sont créés. Un objet est l'objet clé utilisé comme paire clé-valeur, et l'autre est la clé Un objet de valeur de paires de valeurs.

C'est-à-dire que chaque entrée stocke un objet redisObject de "paire clé-valeur", et les données correspondantes sont trouvées via le pointeur de redisObject.

typedef struct redisObject{
    //类型
   unsigned type:4;
   //编码
   unsigned encoding:4;
   //指向底层数据结构的指针
   void *ptr;
    //...
 }robj;

Que faire en cas de conflit de hachage ?

Redis résout les conflits grâce au

hachage en chaîne : c'est-à-dire que les éléments du même compartiment sont enregistrés à l'aide d'une liste chaînée. Cependant, lorsque la liste chaînée est trop longue, les performances de recherche peuvent se détériorer. Par conséquent, afin de rechercher la vitesse, Redis utilise deux tables de hachage globales. Utilisé pour les opérations de rehachage afin d'augmenter le nombre de compartiments de hachage existants et de réduire les conflits de hachage.

Commencez à utiliser la « table de hachage 1 » pour enregistrer les données de la paire clé-valeur par défaut, et la « table de hachage 2 » n'a pas d'espace alloué pour le moment. Lorsque de plus en plus de données déclenchent l'opération de rehachage, les opérations suivantes sont effectuées :

1. Allouez plus d'espace à la « table de hachage 2 » ;
2. Remappez et copiez les données de la « table de hachage 1 » vers la « table de hachage 2 » ;
3. Libérez l'espace de la table de hachage 1.

Il convient de noter que le processus de remappage des données de la table de hachage 1 vers la table de hachage 2 n'est pas un processus ponctuel. Cela entraînera le blocage de Redis et l'incapacité de fournir des services.

Au lieu de cela, rehash progressif est utilisé. Chaque fois qu'une demande client est traitée, elle commence à partir du premier index de la "table de hachage 1" et copie toutes les données à cet emplacement dans la "table de hachage 2", se dispersant ainsi. la répétition en plusieurs requêtes pour éviter un blocage fastidieux.

Comment Redis atteint-il la persistance ? Comment récupérer des données après un crash ? La persistance des données de

Redis utilise la méthode « instantané de données RDB » pour obtenir une récupération rapide après un temps d'arrêt. Cependant, l'exécution trop fréquente d'instantanés de données complètes entraîne deux graves problèmes de performances :

1. Générer fréquemment des fichiers RDB et les écrire sur le disque, ce qui entraîne une pression excessive sur le disque. Il apparaîtra que le RDB précédent n'a pas encore été exécuté et le suivant recommence à être généré, tombant dans une boucle infinie.
2. La sortie du sous-processus bgsave bloquera le thread principal. Plus la mémoire du thread principal est grande, plus le temps de blocage est long.

Redis a donc également conçu le journal de post-écriture AOF pour enregistrer les instructions de modification de la mémoire.

Intervieweur : Qu'est-ce qu'un instantané de mémoire RDB ?

Pendant que Redis exécute la commande "write", les données de la mémoire continueront de changer. Ce que l'on appelle l'instantané de mémoire fait référence aux données d'état des données dans la mémoire Redis à un moment donné.

C'est comme si le temps était figé à un certain moment. Lorsque nous prenons des photos, nous pouvons enregistrer complètement le moment à un certain moment grâce aux photos.

Redis est similaire à ceci, il capture les données à un certain moment sous la forme d'un fichier et les écrit sur le disque. Ce fichier d'instantané est appelé RDB file RDB est l'abréviation de Redis DataBase.

Lors de la récupération de données, lisez le fichier RDB directement dans la mémoire pour terminer la récupération.

Interviewer : Lors de la génération de RDB, Redis peut-il gérer les requêtes d'écriture en même temps ?

Oui, Redis utilise la technologie de copie sur écriture multi-processus du système d'exploitation COW (Copy On Write) pour obtenir la persistance des instantanés et garantir la cohérence des données.

Redis appellera la fonction glibc fork pour générer un processus enfant pendant la persistance. La persistance de l'instantané est entièrement gérée par le processus enfant et le processus parent continue de traiter les demandes des clients. fork产生一个子进程，快照持久化完全交给子进程来处理，父进程继续处理客户端请求。

当主线程执行写指令修改数据的时候，这个数据就会复制一份副本， bgsave 子进程读取这个副本数据写到 RDB 文件。

这既保证了快照的完整性，也允许主线程同时对数据进行修改，避免了对正常业务的影响。

面试官：那 AOF 又是什么？

AOF 日志记录了自 Redis 实例创建以来所有的修改性指令序列，那么就可以通过对一个空的 Redis 实例顺序执行所有的指令，也就是「重放」，来恢复 Redis 当前实例的内存数据结构的状态。

Redis 提供的 AOF 配置项appendfsync写回策略直接决定 AOF 持久化功能的效率和安全性。

• always：同步写回，写指令执行完毕立马将 aof_buf缓冲区中的内容刷写到 AOF 文件。
• everysec：每秒写回，写指令执行完，日志只会写到 AOF 文件缓冲区，每隔一秒就把缓冲区内容同步到磁盘。
• no： 操作系统控制，写执行执行完毕，把日志写到 AOF 文件内存缓冲区，由操作系统决定何时刷写到磁盘。

没有两全其美的策略，我们需要在性能和可靠性上做一个取舍。

面试官：既然 RDB 有两个性能问题，那为何不用 AOF 即可。

AOF 写前日志，记录的是每个「写」指令操作。不会像 RDB 全量快照导致性能损耗，但是执行速度没有 RDB 快，同时日志文件过大也会造成性能问题。

所以，Redis 设计了一个杀手锏「AOF 重写机制」，Redis 提供了 bgrewriteaof

Lorsque le thread principal exécute une commande d'écriture pour modifier les données, une copie des données sera effectuée et le processus enfant bgsave lira les données de copie et les écrira dans le fichier RDB.

Cela garantit non seulement l'intégrité de l'instantané, mais permet également au thread principal de modifier les données en même temps, évitant ainsi tout impact sur les activités normales.

Intervieweur : Alors, qu’est-ce que l’AOF ?

🎜🎜Le journal AOF enregistre toutes les séquences d'instructions modifiées depuis la création de l'instance Redis. Vous pouvez ensuite restaurer les données mémoire de l'instance Redis actuelle en exécutant toutes les instructions séquentiellement sur une instance Redis vide, c'est-à-dire "replay". L'état de la structure. 🎜🎜La stratégie de réécriture de l'élément de configuration AOF appendfsync fournie par Redis détermine directement l'efficacité et la sécurité de la fonction de persistance AOF. 🎜

🎜🎜always🎜 : Réécriture synchrone, le contenu du tampon aof_buf sera vidé dans le fichier AOF immédiatement après l'exécution de la commande d'écriture. 🎜🎜🎜everysec🎜 : réécrivez chaque seconde. Une fois la commande d'écriture exécutée, le journal sera uniquement écrit dans le tampon du fichier AOF et le contenu du tampon sera synchronisé avec le disque toutes les secondes. 🎜🎜🎜non : 🎜 Contrôlé par le système d'exploitation, une fois l'exécution de l'écriture terminée, le journal est écrit dans la mémoire tampon du fichier AOF et le système d'exploitation décide quand le vider sur le disque. 🎜

🎜Il n'y a pas de stratégie du meilleur des deux mondes, nous devons faire un compromis entre performances et fiabilité. 🎜🎜🎜Interviewer : Puisque RDB a deux problèmes de performances, pourquoi ne pas utiliser AOF. 🎜🎜🎜Le journal de pré-écriture AOF enregistre chaque opération de commande "écriture". Cela n'entraînera pas de perte de performances comme l'instantané complet RDB, mais la vitesse d'exécution n'est pas aussi rapide que RDB. Dans le même temps, des fichiers journaux trop volumineux entraîneront également des problèmes de performances. 🎜🎜Ainsi, Redis a conçu un "mécanisme de réécriture AOF". Redis fournit la commande bgrewriteaof pour affiner le journal AOF. 🎜🎜Le principe est d'ouvrir un sous-processus pour parcourir la mémoire et de la convertir en une série d'instructions d'opération Redis, qui sont sérialisées dans un nouveau fichier journal AOF. Une fois la sérialisation terminée, le journal AOF incrémentiel généré pendant l'opération est ajouté au nouveau fichier journal AOF. Une fois l'ajout terminé, l'ancien fichier journal AOF est immédiatement remplacé et le travail d'amincissement est terminé. 🎜🎜🎜🎜🎜🎜Intervieweur : Comment obtenir le moins de perte de données possible tout en tenant compte des performances ? 🎜

Lors du redémarrage de Redis, nous utilisons rarement rdb pour restaurer l'état de la mémoire car une grande quantité de données sera perdue. Nous utilisons généralement la relecture des journaux AOF, mais les performances de la relecture des journaux AOF sont beaucoup plus lentes que celles de RDB, donc lorsque l'instance Redis est volumineuse, le démarrage prend beaucoup de temps.

Redis 4.0 Afin de résoudre ce problème, il apporte une nouvelle option de persistance - Persistance hybride. Stockez le contenu du fichier rdb avec le fichier journal AOF incrémentiel. Le journal AOF ici n'est plus le journal complet, mais le journal AOF incrémentiel qui se produit pendant la période allant du début de la persistance à la fin de la persistance. Habituellement, cette partie du journal AOF est très petite. Donc

lorsque Redis redémarre, vous pouvez d'abord charger le contenu rdb, puis relire le journal AOF incrémentiel, qui peut remplacer complètement la relecture complète du fichier AOF précédente, et l'efficacité du redémarrage est grandement améliorée

. Synchronisation des données de l'architecture maître-esclave Redis

Redis fournit un mode maître-esclave, qui copie une copie redondante des données sur d'autres serveurs Redis via la réplication maître-esclave.

Intervieweur : Comment assurer la cohérence des données entre maître et esclave ?

Afin d'assurer la cohérence des données des réplicas, l'architecture maître-esclave adopte une méthode de séparation lecture-écriture.

Opération de lecture : les bibliothèques maître et esclave peuvent être exécutées ;

• Opération d'écriture : la bibliothèque maître l'exécute en premier, puis synchronise l'opération d'écriture avec la bibliothèque esclave

Intervieweur : Maître- ; la réplication esclave a d'autres fonctions Quoi ?

Récupération après panne : lorsque le nœud maître est en panne, d'autres nœuds peuvent toujours fournir des services ;

1. Équilibrage de charge : le nœud maître fournit des services d'écriture et le nœud esclave fournit des services de lecture pour partager la pression ; haute disponibilité : implémentation de Sentinel et de cluster La fondation est la pierre angulaire de la haute disponibilité.
3. Interviewer : Comment la réplication maître-esclave est-elle mise en œuvre ?

La synchronisation est divisée en trois situations :

Réplication complète de la base de données maître-esclave pour la première fois ;

Synchronisation pendant le fonctionnement normal de la base de données maître-esclave ;

1. Déconnexion du réseau et synchronisation de reconnexion entre la base de données maître-esclave ;
3. Intervieweur : Comment réaliser la première synchronisation ?

Le premier processus de copie de la bibliothèque maître-esclave peut être grossièrement divisé en 3 étapes : l'étape d'établissement de la connexion (c'est-à-dire l'étape de préparation), l'étape de synchronisation des données de la bibliothèque maître vers la bibliothèque esclave et l'étape d'envoyer de nouvelles commandes d'écriture lors de la synchronisation à la bibliothèque esclave

 ;

Établir une connexion : La bibliothèque esclave établira une connexion avec la bibliothèque maître. bibliothèque que la synchronisation est sur le point d'avoir lieu. Une fois que la bibliothèque maître a confirmé la réponse, la synchronisation entre les bibliothèques maître et esclave commence

.

1. La bibliothèque maître synchronise les données avec la bibliothèque esclave : le maître exécute la commande bgsave pour générer un fichier RDB et envoie le fichier à la bibliothèque esclave. En même temps, la bibliothèque principales'ouvre. un tampon de réplication pour chaque esclave pour enregistrer l'esclave. La construction du fichier RDB commence avec toutes les commandes d'écriture reçues. Enregistrez le RDB de la bibliothèque, effacez la base de données, puis chargez les données RDB en mémoire.
2. Envoyer la nouvelle commande d'écriture reçue après RDB à la bibliothèque esclave : l'opération d'écriture après génération du fichier RDB n'est pas enregistrée dans le fichier RDB pour l'instant Afin d'assurer la cohérence des données de la bibliothèque maître-esclave, la bibliothèque maître. sera en mémoire. Utilisez un tampon de réplication pour enregistrer toutes les opérations d'écriture après la génération du fichier RDB. Et envoyez les données à l’intérieur à l’esclave. bgsave命令生成 RDB 文件，并将文件发送给从库，同时主库为每一个 slave 开辟一块 replication buffer 缓冲区记录从生成 RDB 文件开始收到的所有写命令。从库保存 RDB 并清空数据库再加载 RDB 数据到内存中。
3. 发送 RDB 之后接收到的新写命令到从库：在生成 RDB 文件之后的写操作并没有记录到刚刚的 RDB 文件中，为了保证主从库数据的一致性，所以主库会在内存中使用一个叫 replication buffer 记录 RDB 文件生成后的所有写操作。并将里面的数据发送到 slave。

面试官：主从库间的网络断了咋办？断开后要重新全量复制么？

在 Redis 2.8 之前，如果主从库在命令传播时出现了网络闪断，那么，从库就会和主库重新进行一次全量复制，开销非常大。

从 Redis 2.8 开始，网络断了之后，主从库会采用增量复制的方式继续同步。

增量复制：用于网络中断等情况后的复制，只将中断期间主节点执行的写命令发送给从节点，与全量复制相比更加高效。

断开重连增量复制的实现奥秘就是 repl_backlog_buffer 缓冲区，不管在什么时候 master 都会将写指令操作记录在 repl_backlog_buffer 中，因为内存有限， repl_backlog_buffer 是一个定长的环形数组，如果数组内容满了，就会从头开始覆盖前面的内容。

master 使用 master_repl_offset记录自己写到的位置偏移量，slave 则使用 slave_repl_offset记录已经读取到的偏移量。

当主从断开重连后，slave 会先发送 psync 命令给 master，同时将自己的 runID，slave_repl_offset发送给 master。

master 只需要把 master_repl_offset与 slave_repl_offset

🎜🎜Intervieweur : Que dois-je faire si le réseau entre les bases de données maître et esclave est déconnecté ? Dois-je copier à nouveau le volume complet après la déconnexion ? 🎜🎜🎜Avant Redis 2.8, si la bibliothèque maître-esclave rencontrait une interruption du réseau lors de la propagation des commandes, alors la bibliothèque esclave effectuait à nouveau une copie complète avec la bibliothèque maître, ce qui coûtait très cher. 🎜🎜À partir de Redis 2.8, une fois le réseau déconnecté, la bibliothèque maître-esclave continuera à se synchroniser à l'aide de la réplication incrémentielle. 🎜🎜Réplication incrémentale : 🎜Utilisée pour la réplication après des interruptions du réseau et d'autres situations. Seules les commandes d'écriture exécutées par le nœud maître pendant l'interruption sont envoyées aux nœuds esclaves, ce qui est plus efficace que la réplication complète🎜. 🎜🎜Le secret pour déconnecter et reconnecter la réplication incrémentielle est le tampon repl_backlog_buffer. Peu importe le moment, le maître enregistrera l'opération d'instruction d'écriture dans repl_backlog_buffer, car la mémoire est limitée. repl_backlog_buffer est un tableau circulaire de longueur fixe 🎜Si le contenu du tableau est plein, le contenu précédent sera écrasé depuis le début🎜. 🎜🎜Le maître utilise master_repl_offset pour enregistrer le décalage de position qu'il écrit, et l'esclave utilise slave_repl_offset pour enregistrer le décalage qu'il a lu. 🎜🎜🎜🎜Soyez le maître Après s'être déconnecté et reconnecté, l'esclave enverra d'abord la commande psync au maître, et enverra en même temps son runID et son slave_repl_offset au maître. 🎜🎜Master n'a besoin que de synchroniser les commandes entre master_repl_offset et slave_repl_offset avec la bibliothèque esclave. 🎜

Le processus d'exécution de la copie incrémentielle est le suivant :

Intervieweur : Après avoir terminé la synchronisation complète, comment synchroniser les données pendant le fonctionnement normal ?

Lorsque la bibliothèque maître-esclave termine la réplication complète, une connexion réseau sera maintenue entre elles. La bibliothèque maître utilisera cette connexion pour synchroniser les opérations de commande suivantes reçues successivement avec la bibliothèque esclave. Ce processus est également appelé en fonction de connexions longues. . Propagation des commandes, le but de l'utilisation de connexions longues est d'éviter la surcharge causée par l'établissement fréquent de connexions.

Questions et réponses sur le principe Sentinel

Intervieweur : Bien sûr, j'en sais tellement, connaissez-vous le principe du cluster Sentinel ?

Sentinel est un mode de fonctionnement de Redis. Il se concentre sur la surveillance de l'état d'exécution des instances Redis (nœuds maîtres, nœuds esclaves) et peut réaliser la sélection maître et la sélection maître-esclave via une série de mécanismes en cas de défaillance du nœud maître. Basculez et implémentez le basculement pour garantir la disponibilité de l'ensemble du système Redis.

Son schéma d'architecture est le suivant :

Redis Sentinel a les capacités suivantes :

• Surveillance : Surveillez en permanence si le maître et l'esclave sont dans l'état de fonctionnement attendu.
• Changer automatiquement de base de données maître : lorsque le maître échoue, Sentinel démarre le processus de récupération automatique après panne : sélectionnez l'un des esclaves comme nouveau maître.
• Notification : laissez l'esclave exécuter la réplique pour se synchroniser avec le nouveau maître et avertir le client pour établir une connexion avec le nouveau maître ;

Intervieweur : Comment les sentinelles se connaissent-elles ?

La sentinelle établit la communication avec le maître et utilise le mécanisme de publication/abonnement fourni par le maître pour publier ses propres informations, comme la taille et le poids, si vous êtes célibataire, IP, port...

le maître dispose d'un espace dédié __sentinel__:hello Les canaux sont utilisés pour publier et s'abonner aux messages entre sentinelles.

C'est comme le groupe WeChat __sentinel__:hello. Sentinel utilise le groupe WeChat créé par le maître pour publier ses propres actualités, et en même temps prêter attention aux actualités publiées par d'autres sentinelles__sentinel__:hello 的专用通道，用于哨兵之间发布和订阅消息。这就好比是 __sentinel__:hello 微信群，哨兵利用 master 建立的微信群发布自己的消息，同时关注其他哨兵发布的消息。

面试官：哨兵之间虽然建立连接了，但是还需要和 slave 建立连接，不然没法监控他们呀，如何知道 slave 并监控他们的？

关键还是利用 master 来实现，哨兵向 master 发送 INFO 命令， master 掌门自然是知道自己门下所有的 salve 小弟的。所以 master 接收到命令后，便将 slave 列表告诉哨兵。

哨兵根据 master 响应的 slave 名单信息与每一个 salve 建立连接，并且根据这个连接持续监控哨兵。

Cluster 集群连环炮

面试官：除了哨兵以外，还有其他的高可用手段么？

有 Cluster 集群实现高可用，哨兵集群监控的 Redis 集群是主从架构，无法很想拓展。使用 Redis Cluster 集群，主要解决了大数据量存储导致的各种慢问题，同时也便于横向拓展。

在面向百万、千万级别的用户规模时，横向扩展的 Redis 切片集群会是一个非常好的选择。

面试官：什么是 Cluster 集群？

Redis 集群是一种分布式数据库方案，集群通过分片（sharding）来进行数据管理（「分治思想」的一种实践），并提供复制和故障转移功能。

将数据划分为 16384 的 slots，每个节点负责一部分槽位。槽位的信息存储于每个节点中。

它是去中心化的，如图所示，该集群有三个 Redis 节点组成，每个节点负责整个集群的一部分数据，每个节点负责的数据多少可能不一样。

三个节点相互连接组成一个对等的集群，它们之间通过 Gossip.

Intervieweur : Bien que les sentinelles aient établi une connexion entre elles, elles doivent encore établir une connexion avec l'esclave, sinon, elles ne peuvent pas être surveillées. Comment connaître l'esclave et le surveiller ?

La clé est d'utiliser le maître pour y parvenir. La sentinelle envoie la commande INFO au maître. Le maître connaît naturellement tous les garçons salve sous lui. Ainsi, une fois que le maître a reçu la commande, il indique à la sentinelle la liste des esclaves.
1. La sentinelle établit une connexion avec chaque esclave sur la base des informations de la liste d'esclaves répondues par le maître et surveille en permanence la sentinelle en fonction de cette connexion.
2. 

3. Cluster Cluster Serial Cannon

Intervieweur : En plus des sentinelles, existe-t-il d'autres méthodes de haute disponibilité ?

Il existe un cluster Cluster pour atteindre la haute disponibilité. Le cluster Redis surveillé par le cluster Sentinel a une architecture maître-esclave et ne peut pas être facilement étendu.

L'utilisation du cluster Redis Cluster résout principalement divers problèmes de lenteur causés par un stockage de données volumineux et facilite également l'expansion horizontale.

🎜Face à des millions ou des dizaines de millions d'utilisateurs, les clusters de découpage Redis évolutifs horizontalement seront un très bon choix. 🎜🎜🎜🎜Intervieweur : Qu'est-ce qu'un Cluster ? 🎜🎜🎜Le cluster Redis est une solution de base de données distribuée. Le cluster gère les données via le sharding (une pratique de « diviser pour mieux régner ») et fournit des fonctions de réplication et de basculement. 🎜🎜Divisez les données en 16384 emplacements, et chaque nœud est responsable d'une partie des emplacements. Les informations sur les emplacements sont stockées dans chaque nœud. 🎜🎜Il est décentralisé. Comme le montre la figure, le cluster se compose de trois nœuds Redis. Chaque nœud est responsable d'une partie des données de l'ensemble du cluster. La quantité de données dont chaque nœud est responsable peut être différente. 🎜🎜🎜🎜三Les nœuds sont connectés les uns aux autres pour former un cluster peer-to-peer. Ils échangent des informations de cluster entre eux via le protocole Gossip. Enfin, chaque nœud enregistre l'allocation des emplacements des autres nœuds. 🎜🎜🎜Intervieweur : Comment les emplacements de hachage sont-ils mappés aux instances Redis ? 🎜🎜🎜🎜Selon la clé de la paire clé-valeur, utilisez l'algorithme CRC16 pour calculer une valeur de 16 bits ; 🎜🎜La valeur de 16 bits est modulo 16384, et un nombre compris entre 0 et 16383 est obtenu pour représenter le emplacement de hachage correspondant à la clé. 🎜🎜Localisez l'instance correspondante en fonction des informations sur l'emplacement. 🎜🎜🎜La relation de mappage entre les données des paires clé-valeur, les emplacements de hachage et les instances Redis est la suivante : 🎜🎜🎜🎜🎜🎜Intervieweur : Comment le cluster implémente-t-il le basculement ? 🎜Les nœuds du cluster

Redis utilisent le protocole Gossip pour diffuser leur statut et les changements dans leurs connaissances de l'ensemble du cluster. Par exemple, si un nœud découvre qu'un certain nœud est perdu (PFail), il diffusera ces informations à l'ensemble du cluster et d'autres nœuds pourront également recevoir ces informations de connexion perdue.

Si un nœud reçoit que le nombre de déconnexions d'un certain nœud (PFail Count) a atteint la majorité du cluster, il peut marquer le nœud comme déterminé comme étant hors ligne (Fail), puis le diffuser à l'ensemble du cluster, forcer les autres nœuds à recevoir également le fait que le nœud est devenu hors ligne et à effectuer immédiatement un commutateur maître-esclave sur le nœud perdu.

Intervieweur : Comment le client détermine-t-il sur quelle instance les données consultées sont distribuées ?

L'instance Redis enverra ses informations d'emplacement de hachage à d'autres instances du cluster via le protocole Gossip, réalisant ainsi la diffusion des informations d'allocation d'emplacement de hachage.

De cette façon, chaque instance du cluster dispose d'informations sur les relations de mappage entre tous les emplacements de hachage et les instances.

Lorsque le client se connecte à une instance, l'instance répond au client avec la relation de mappage entre l'emplacement de hachage et l'instance, et le client met en cache les informations de mappage entre l'emplacement de hachage et l'instance localement.

Lorsque le client fait une demande, il calculera l'emplacement de hachage correspondant à la clé, localisera l'instance où se trouvent les données via les informations de mappage d'instance d'emplacement de hachage mises en cache localement, puis enverra la demande à l'instance correspondante.

Intervieweur : Qu'est-ce que le mécanisme de redirection Redis ?

La relation de mappage entre les emplacements de hachage et les instances a changé en raison de nouvelles instances ou de la redistribution de l'équilibrage de charge. Le client envoie la demande à l'instance. L'instance Redis dira au client d'envoyer la demande. à d'autres instances.

Redis informe le client via les erreurs MOVED et ASK.

MOVED

MOVED Erreur (équilibrage de charge, les données ont été migrées vers d'autres instances) : lorsque le client envoie une demande d'opération de paire clé-valeur à une instance et que l'emplacement où se trouve la clé n'est pas de sa propre responsabilité , cette instance renverra une erreur MOVED pour indiquer au nœud d'être responsable de l'emplacement.

Dans le même temps, le client mettra également à jour le cache local pour mettre à jour correctement la relation correspondante entre le slot et l'instance Redis.

DEMANDER

S'il y a beaucoup de données dans un certain emplacement, une partie sera migrée vers la nouvelle instance et une partie ne sera pas migrée.

Si la clé demandée est trouvée sur le nœud actuel, exécutez la commande directement, sinon une réponse d'erreur ASK sera requise.

Lorsque la migration du slot n'est pas terminée, si le Slot auquel il faut accéder à la clé est en cours de migration de l'instance 1 vers l'instance 2 (si la clé n'est plus dans l'instance 1), l'instance 1 renverra un message d'erreur ASK à le client : Demande du client L'emplacement de hachage où se trouve la clé est en cours de migration vers l'instance 2. Vous envoyez d'abord une commande ASKING à l'instance 2, puis envoyez la commande d'opération .

Par exemple, si le client demande de localiser l'emplacement 16330 avec key = "Compte officiel : Code Byte" sur l'instance 172.17.18.1, le nœud 1 exécutera directement la commande s'il peut être trouvé, sinon il répondra par une erreur ASK et demandez au client de rediriger. Le nœud cible en cours de migration est 172.17.18.2.

Remarque : L'instruction d'erreur ASK ne met pas à jour les informations d'allocation d'emplacement de hachage mises en cache par le client.

Résumé

Cet article passe principalement en revue le contenu principal de Redis, impliquant la structure des données, le modèle de mémoire, le modèle IO, le RDB et l'AOF persistants, le principe de réplication maître-esclave, le principe sentinelle et le principe de cluster.

Adresse originale : https://juejin.cn/post/6976257378094481444

Auteur : Code Brother Byte

Pour plus de connaissances sur la programmation, veuillez visiter : Vidéo de 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!