Afin d'atteindre la haute disponibilité (HA) dans Redis, les deux méthodes suivantes sont utilisées :
Réplication maître-esclave des données.
Utilisez des sentinelles pour surveiller le fonctionnement des nœuds de données. Une fois qu'il y a un problème avec le nœud maître, le service continuera depuis le haut du nœud esclave.
Dans Redis, les données répliquées par le nœud maître-esclave peuvent être divisées en réplication complète et réplication partielle.
La copie complète est implémentée à l'aide de la commande snyc Le processus est le suivant :
Envoyer la commande de synchronisation du serveur vers le serveur principal.
Après avoir reçu la commande de synchronisation, le serveur maître appelle la commande bgsave pour générer le fichier ***rdb et synchronise ce fichier avec le serveur esclave de cette façon, après que le serveur esclave ait chargé le fichier rdb, l'état. sera exécuté avec le serveur maître bgsave Cohérence dans la transmission des ordres.
Le serveur maître synchronise les commandes d'écriture enregistrées dans le tampon de commandes avec le serveur esclave, et le serveur esclave exécute ces commandes, de sorte que l'état du serveur esclave soit cohérent avec l'état actuel du serveur maître.
Le principal problème avec la fonction de copie complète de l'ancienne version est que lorsque le serveur esclave est déconnecté et reconnecté, même s'il y a déjà des données sur le serveur esclave, une copie complète doit être effectuée. Ceci est très inefficace. , donc La nouvelle version de Redis a apporté des améliorations dans cette partie.
La dernière version de Redis utilise la commande psync pour remplacer la commande sync La commande psync peut non seulement réaliser une synchronisation complète, mais également une synchronisation partielle.
Les deux parties qui effectuent la réplication, les serveurs maître et esclave, maintiendront respectivement un décalage de réplication :
Chaque fois que le serveur maître synchronise N octets de données avec le serveur esclave, il modifiera lui-même Le décalage de copie + N.
Chaque fois que le serveur esclave synchronise N octets de données du serveur maître, il modifiera son propre décalage de réplication +N.
Le serveur principal maintient en interne une file d'attente premier entré, premier sorti de longueur fixe comme tampon du backlog de réplication, avec une taille par défaut de 1 Mo.
Lorsque le serveur maître effectue la propagation des commandes, il synchronise non seulement la commande d'écriture avec le serveur esclave, mais écrira également la commande d'écriture dans le tampon du backlog de réplication.
Chaque serveur Redis a son ID d'exécution est automatiquement généré par le serveur lors de son démarrage. Le serveur maître enverra son propre ID d'exécution au serveur esclave, et le serveur esclave l'enverra. l'ID d'exécution du serveur maître. L'ID d'exécution est enregistré.
Lors de la synchronisation après la déconnexion et la reconnexion du serveur esclave Redis, la progression de la synchronisation est jugée en fonction de l'ID en cours d'exécution :
Si l'ID en cours d'exécution du serveur principal enregistré sur le serveur esclave est cohérent avec l'ID en cours d'exécution du serveur principal actuel, on considère cette fois que le serveur principal qui a été déconnecté et reconnecté est le serveur principal précédemment répliqué, et le serveur principal peut continuer à tenter des opérations de synchronisation partielle.
Sinon, si l'ID du serveur principal exécutant est différent entre les deux avant et après, on considère que le processus de synchronisation complet est terminé.
Avec les préparations précédentes, commençons à analyser le processus de commande psync :
Si le serveur esclave n'a copié aucun serveur maître auparavant, ou si la commande slaveof no one n'a été exécutée auparavant , puis le serveur esclave enverra la commande psync ? -1 au serveur maître, demandant au serveur maître de synchroniser toutes les données.
Sinon, si le serveur esclave a déjà synchronisé certaines données auparavant, alors le serveur esclave envoie la commande pync
Une fois que le serveur maître a reçu la commande psync dans les deux premiers cas, les trois possibilités suivantes se produiront :
Le serveur maître renvoie une réponse +fullresync
Si le serveur principal répond par +continue, cela signifie que le serveur principal et le serveur esclave effectuent des opérations de synchronisation partielle des données, et que les données manquantes du serveur esclave peuvent être synchronisées.
Si le serveur maître répond avec -err, cela signifie que la version du serveur maître est inférieure à 2.8 et ne peut pas reconnaître la commande psync. À ce moment, le serveur esclave enverra une commande de synchronisation au serveur maître pour effectuer une opération complète. synchronisation complète des données.
Redis utilise le mécanisme sentinelle pour atteindre la haute disponibilité (HA). Son principe de fonctionnement général est le suivant :
Redis utilise un ensemble de nœuds sentinelles pour surveiller la disponibilité du maître. -service redis esclave.
Une fois découvert que le nœud maître Redis a échoué, un nœud sentinelle sera élu leader.
Sentinel*** sélectionne ensuite un nœud Redis parmi les nœuds Redis esclaves restants comme nouveau nœud Redis principal pour fournir des services externes.
Ce qui précède divise les nœuds Redis en deux catégories :
Nœud Sentinelle (sentinel) : Responsable de la surveillance du fonctionnement du nœud.
Data node : le nœud Redis qui répond normalement aux requêtes des clients, divisé en maître et esclave.
Ce qui précède est le processus général. Ce processus doit résoudre les problèmes suivants :
Comment surveiller les nœuds de données Redis ?
Comment déterminer si un nœud de données Redis n'est pas valide ?
Comment choisir un nœud sentinelle*** ?
Quelle est la base sur laquelle le nœud sentinelle sélectionne le nouveau nœud Redis principal ?
Répondons à ces questions une par une.
Le nœud sentinelle surveille la disponibilité du service du nœud de données Redis via trois tâches de surveillance planifiées.
Toutes les 10 secondes, chaque nœud sentinelle enverra la commande info aux nœuds de données Redis maître et esclave pour obtenir de nouvelles informations de topologie.
Les informations de topologie Redis incluent :
Le rôle de ce nœud : maître ou esclave.
L'adresse et les informations de port des nœuds maître et esclave.
De cette façon, le nœud sentinelle peut obtenir automatiquement les informations du nœud esclave à partir de la commande info, de sorte que les informations du nœud esclave ajoutées ultérieurement peuvent être automatiquement détectées sans configuration explicite.
Toutes les 2 secondes, chaque nœud sentinelle synchronisera ses propres informations de nœud maître et les informations actuelles du nœud sentinelle avec le canal __sentinel__:hello du nœud de données Redis, car d'autres nœuds sentinelles s'abonnent également. vers ce canal, cette opération échange donc des informations sur le nœud maître et les nœuds sentinelles entre les nœuds sentinelles.
Cette opération accomplit en fait deux choses : * Découvrir un nouveau nœud sentinelle : Si un nouveau nœud sentinelle rejoint, les informations du nouveau nœud sentinelle sont enregistrées à ce moment, et une connexion est ensuite établie avec le nœud sentinelle. Réécrivez-le de la manière suivante : * Échangez les informations d'état du nœud maître afin que nous puissions déterminer objectivement si le nœud maître est hors ligne.
Toute la seconde, chaque nœud sentinelle envoie une commande ping au maître, aux nœuds de données esclaves et aux autres nœuds sentinelles pour la détection du rythme cardiaque. Cette détection du rythme cardiaque est le jugement subjectif ultérieur que le nœud de données. est hors ligne conformément à.
La troisième tâche de détection de rythme cardiaque parmi les trois tâches de surveillance ci-dessus, si aucune réponse valide n'est reçue après le délai d'arrêt configuré après millisecondes, le nœud de données est alors pris en compte "subjectivement hors ligne (sdown)".
Pourquoi est-ce appelé « subjectif hors ligne » ? Étant donné que dans un système distribué, plusieurs machines travaillent ensemble, diverses situations peuvent se produire dans le réseau. Le jugement d'un seul nœud ne suffit pas pour considérer qu'un nœud de données est hors ligne. Cela nécessite le processus ultérieur de « hors ligne objectif ». .
Lorsqu'un nœud sentinelle pense que le nœud maître est subjectivement hors ligne, le nœud sentinelle doit utiliser la commande "sentinel is-master-down-by addr" pour consulter d'autres nœuds sentinelles si le nœud maître est hors ligne, si plus de la moitié des nœuds sentinelles répondent qu'ils sont hors ligne, le nœud maître est considéré comme « objectivement hors ligne » à ce moment-là.
Lorsque le nœud maître se déconnecte objectivement, un nœud sentinelle doit être élu comme sentinelle *** pour terminer le travail ultérieur de sélection d'un nouveau nœud maître.
L'idée générale de cette élection est la suivante :
Chaque nœud sentinelle postule pour devenir une sentinelle *** en envoyant la commande "sentinel is-master-down-by addr" aux autres nœuds sentinelles.
Lorsque chaque nœud sentinelle reçoit une commande "sentinel is-master-down-by addr", il est uniquement autorisé à voter pour les nœuds ***, et la commande des autres nœuds sera rejetée.
Si un nœud sentinelle reçoit plus de la moitié des votes d'approbation, il devient une sentinelle***.
Si une sentinelle*** n'est pas sélectionnée dans un certain délai lors des trois premières étapes, la prochaine élection recommencera.
Vous pouvez voir que le processus d'élection d'un *** est très similaire au processus d'élection d'un leader en radeau.
Parmi les nœuds esclaves Redis restants, sélectionnez un nouveau nœud maître dans l'ordre suivant :
Filtrez les nœuds de données « malsains » : tels que les nœuds esclaves hors ligne subjectifs, la déconnexion sur le ligne, les nœuds qui n'ont pas répondu à la commande ping du nœud sentinelle dans les cinq secondes et les nœuds esclaves qui ont perdu le contact avec le nœud maître.
S'il existe un nœud esclave avec priorité esclave ***, renvoyez le nœud sinon, continuez à exécuter le processus suivant.
Sélectionnez le nœud esclave avec décalage de copie ***, ce qui signifie que les données sur ce nœud esclave sont les plus complètes S'il existe, il reviendra s'il n'existe pas et poursuivra le processus suivant.
À ce stade, l'état de tous les nœuds esclaves restants est le même, sélectionnez le nœud esclave avec le plus petit runid.
Après avoir sélectionné le nouveau nœud maître, un processus *** est requis pour que le nœud devienne le nouveau nœud maître :
Sentinel*** émet la commande "slaveof no one" au nœud esclave sélectionné à l'étape précédente pour faire de ce nœud le nœud maître.
Sentinel*** envoie des commandes aux nœuds esclaves restants pour en faire des nœuds esclaves du nouveau nœud maître.
L'ensemble de nœuds sentinelles mettra à jour le nœud maître d'origine vers le nœud esclave, et lors de sa récupération, il lui sera ordonné de copier les données du nouveau nœud maître.
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!
Logiciel de base de données couramment utilisé
Que sont les bases de données en mémoire ?
Lequel a une vitesse de lecture plus rapide, mongodb ou redis ?
Comment utiliser Redis comme serveur de cache
Comment Redis résout la cohérence des données
Comment MySQL et Redis assurent-ils la cohérence des doubles écritures ?
Quelles données le cache Redis stocke-t-il généralement ?
Quels sont les 8 types de données de Redis
![[Web front-end] Démarrage rapide de Node.js](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
