Comment Redis implémente la réplication maître-esclave

En présentant Redis plus tôt, nous opérons tous sur un serveur, ce qui signifie que les opérations de lecture, d'écriture et de sauvegarde sont toutes effectuées sur un serveur Redis. À mesure que le nombre de visites de projets augmente, le besoin d'opérations de serveur Redis augmentera. De plus, bien que Redis soit très rapide en lecture et en écriture, cela entraînera également un certain retard dans une certaine mesure. Afin de résoudre le problème du volume d'accès important, une méthode généralement adoptée est l'architecture maître-esclave Maître /. L'esclave, le maître est principalement destiné à l'écriture et l'esclave est principalement destiné à la lecture. Une fois le nœud maître mis à jour, il se synchronisera automatiquement avec le nœud esclave esclave en fonction de la configuration.

Nous présenterons ensuite comment construire une architecture maître-esclave.

ps : Ici, je simule plusieurs serveurs Redis sur une seule machine Par rapport à l'environnement de production réel, la configuration de base est la même, seuls l'adresse IP et le numéro de port changent.

　

1 Modifiez le fichier de configuration

Tout d'abord, copiez le fichier de configuration redis.conf en trois copies et simulez trois copies. respectivement en modifiant le port. Un serveur Redis.

　

　Ensuite, nous modifions respectivement ces trois fichiers redis.conf.

　①、Modify daemonize yes

　

Indique que Redis est spécifié pour être démarré en tant que un processus démon (démarrage en arrière-plan) Lorsqu'il est exécuté en tant que démon, il écrira le pid dans le fichier /var/redis/run/redis_6379.pid par défaut

　③, configurez le port port#🎜🎜 #

　

　

④、Configurer le nom du fichier journal

🎜 #　# 🎜🎜#⑤、Configurer le nom du fichier rdb

　

Configurez 6380redis.conf et 6381redis.conf une fois dans l'ordre, puis la configuration est terminée . Ensuite, nous démarrons respectivement ces trois services.

​ Saisissez respectivement les trois clients Redis suivants :

1

2

3

redis-cli -p 6379

redis-cli -p 6380

redis-cli -p 6381

#🎜🎜 #

2. Définissez la relation maître-esclave

　① Vérifiez le rôle du nœud via la commande de réplication d'informations

　

　

Nous avons constaté que ces trois nœuds jouent tous le rôle de maître. Comment convertir les nœuds 6380 et 6381 en rôle de nœud esclave ?

　②. Sélectionnez les ports 6380 et 6381 et exécutez la commande : SLAVEOF 127.0.0.1 6379

　

　Regardons les informations du nœud 6379 :

　

O Une fois le service redémarré, configurez-le via le maître de commande -la relation esclave sera invalide. Cette relation peut être enregistrée définitivement en configurant le fichier redis.conf.

3. Testez la relation maître-esclave

　①, Réplication incrémentale

　 Si le nœud maître exécute la commande set k1 v1, le nœud esclave peut-il obtenir k1 ?

　

　

　

　 Comme vous pouvez le voir sur la photo ci-dessus, il est disponible.

　②、Copie complète

　 En exécutant SLAVEOF 127.0.0.1 6379, s'il y a encore des clés avant le nœud maître 6379, après avoir exécuté la commande, le nœud esclave copiera-t-il également toutes les informations précédentes ?

　La réponse est oui, je ne publierai pas les résultats des tests ici.

　③, Séparation maître-esclave en lecture et en écriture

　 Le nœud maître peut-il exécuter des commandes d'écriture et le nœud esclave peut-il exécuter des commandes d'écriture ?

　　

　　La raison ici est la configuration de l'esclave en lecture seule dans le fichier de configuration 6381redis.conf

　　

　Si nous le modifions sur non, il est OK d'exécuter la commande d'écriture.

　

　Mais les données écrites par le nœud esclave ne peuvent pas être obtenues à partir du nœud esclave ou du nœud maître.

　④、Le nœud maître est en panne

　 Si le nœud maître Master raccroche, les rôles des deux nœuds esclaves changeront-ils ?

　　

　　

　 Comme le montre la figure ci-dessus, une fois que le nœud maître Master a raccroché, le rôle du nœud esclave ne changera pas.

　⑤. Récupération après la panne du nœud maître

Après le raccrochement du nœud maître, démarrez immédiatement le nœud maître. Le nœud maître joue-t-il toujours le rôle de maître ?

　

　C'est-à-dire qu'une fois que le nœud maître a raccroché et redémarré, le rôle du nœud maître est restauré.

4. Mode Sentinelle

Grâce à la configuration précédente, il n'y a qu'un seul nœud maître. Une fois le nœud maître raccroché, le nœud esclave ne pourra pas assumer la tâche du nœud maître, et l'ensemble du système le fera. ne pas pouvoir courir. Le mode sentinelle est né de là, car le nœud esclave peut automatiquement prendre en charge les responsabilités du nœud maître, résolvant ainsi le problème des temps d'arrêt du nœud maître.

　 Le mode sentinelle consiste à surveiller si redis fonctionne bien comme prévu de temps en temps (au moins pour s'assurer que le nœud maître existe. S'il y a un problème avec un hôte, la sentinelle définira automatiquement un esclave sous l'hôte). en tant que nouvel hôte et laissez les autres esclaves établir une relation maître-esclave avec le nouvel hôte.

　　

　Étapes pour créer le mode sentinelle :

　①Créez un nouveau fichier sentinel.conf dans le répertoire du fichier de configuration. Le nom ne doit pas être erroné, puis configurez le contenu correspondant

　　

. 1	moniteur sentinelle Le nom de la machine surveillée (nommez-la vous-même) Adresse IP Numéro de port Nombre de votessentinel monitor 被监控机器的名字(自己起名字) ip地址 端口号 得票数

　　

　　分别配置被监控的名字，ip地址，端口号，以及得票数。当主机宕机时，从机需要投票决定谁接替成为主机，得票数达到1时不足以成为主机，必须超过1才可成为主机

　　②、启动哨兵

1	redis-sentinel /etc/redis/sentinel.conf

　🎜🎜　 Configurez respectivement le nom surveillé, l'adresse IP, le numéro de port et le nombre de votes. Lorsque le maître tombe, les esclaves doivent voter pour décider qui prendra la relève en tant que maître. Lorsque le nombre de voix atteint 1, il ne suffit pas de devenir maître. Il doit dépasser 1 pour devenir maître🎜🎜　　②. Démarrez la sentinelle🎜

🎜1🎜🎜🎜🎜 redis-sentinel /etc/redis/sentinel.conf🎜🎜🎜🎜🎜

　Interface de démarrage :

　

　 Ensuite, nous tuons l'hôte 6379, puis voyons quels changements se produisent sur le nœud esclave.

　

Après avoir tué le nœud maître, nous avons vérifié le journal d'impression en arrière-plan et avons constaté que 6381 avaient voté pour devenir le nœud maître.

　　

　À ce moment, nous vérifions les informations du nœud esclave 6381 :

　

　Le nœud 6381 devient automatiquement le nœud maître.

PS : le mode Sentinel présente également un problème de point de défaillance unique. Si la machine Sentinel raccroche, la surveillance ne sera plus possible pour que Sentinel établisse également un cluster Redis Sentinel.

5. Principe de réplication maître-esclave

La fonction de réplication de Redis comprend deux opérations : la synchronisation (sync) et la propagation de commande (propagation de commande).

　①、Synchronisation de l'ancienne version

　Lorsque le nœud esclave émet la commande SLAVEOF pour demander au serveur esclave de copier le serveur maître, le serveur esclave la termine en envoyant une commande SYNC au serveur maître. Les étapes d'exécution de la commande sont :

　1. Envoyez la commande SYNC du serveur au serveur maître

　2. Le serveur maître qui reçoit la commande SYNC exécute la commande BGSAVE, génère un fichier RDB en arrière-plan et utilise un tampon. pour enregistrer toutes les exécutions depuis le début de la commande Write

　　 3. Lorsque la commande BGSAVE du serveur maître est exécutée, le serveur maître enverra le fichier RDB généré par la commande BGSAVE au serveur esclave. Le serveur esclave recevra le fichier RDB et le mettra à jour. l'état du serveur à l'état enregistré dans le fichier RDB.

　4. Le serveur maître envoie également toutes les commandes d'écriture dans le tampon au serveur esclave, et le serveur esclave exécute les commandes correspondantes.

　②、Propagation des commandes

　 Une fois l'opération de synchronisation terminée, le serveur maître effectuera les commandes de modification correspondantes. À ce moment, l'état du serveur esclave et du serveur maître sera incohérent.

　Afin de maintenir la cohérence du statut du serveur maître et du serveur esclave, le serveur maître doit effectuer des opérations de propagation de commandes sur le serveur esclave. Le serveur maître enverra ses propres commandes d'écriture au serveur esclave pour exécution. Une fois que le serveur esclave a exécuté la commande correspondante, l'état des serveurs maître et esclave continue d'être cohérent.

Résumé : Grâce aux opérations synchrones et aux fonctions de propagation des commandes, la fonctionnalité de cohérence maître-esclave peut être bien garantie.

Mais nous considérons un problème. Si le serveur esclave se déconnecte soudainement pendant la synchronisation avec le serveur maître, et qu'à ce moment le serveur maître effectue certaines opérations d'écriture, et que le serveur esclave rétablit la connexion, si nous synchronisons, alors nous devons Générer un fichier RDB du serveur maître et chargez-le sur le serveur esclave. Bien que cela puisse garantir la cohérence, l'état des serveurs maître et esclave est en fait cohérent avant la déconnexion. L'incohérence est que le serveur esclave se déconnecte et que le serveur maître s'exécute après la restauration. la connexion du serveur, pouvons-nous déconnecter uniquement les commandes d'écriture au lieu de l'intégralité de l'instantané RDB ?

　 L'opération de synchronisation est en fait une opération très chronophage. Le serveur maître doit d'abord générer un fichier RDB via la commande BGSAVE, puis envoyer le fichier au serveur esclave, après avoir reçu le fichier du serveur esclave. charge ensuite le fichier et le charge. Pendant cette période, le serveur esclave ne peut pas traiter d'autres commandes.

　Pour résoudre ce problème, Redis utilise une nouvelle commande de synchronisation PSYNC pour remplacer la commande SYNC à partir de la version 2.8. La fonction de resynchronisation partielle de cette commande est utilisée pour résoudre le problème d'efficacité de la réplication après déconnexion. C'est-à-dire que lorsque le serveur esclave se reconnecte au serveur maître après avoir été déconnecté, le serveur maître envoie uniquement les commandes d'écriture exécutées après la déconnexion au serveur esclave. Le serveur esclave n'a besoin que de recevoir et d'exécuter ces commandes d'écriture pour conserver le maître. -cohérence esclave.

6. Inconvénients de la réplication maître-esclave

Bien que la réplication maître-esclave résolve le problème du point de défaillance unique du nœud maître, puisque toutes les opérations d'écriture sont effectuées sur le nœud maître puis synchronisées avec le nœud esclave, il y aura problèmes de synchronisation. Il y a un certain retard lorsque le système est très occupé, le problème de retard sera plus grave, et il deviendra plus grave à mesure que le nombre de nœuds esclaves augmente.

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!