Dans Redis, si la bibliothèque esclave tombe en panne, le client peut continuer à envoyer des messages à la bibliothèque maître et à d'autres bibliothèques esclaves pour les opérations associées. Cependant, si la bibliothèque principale tombe en panne, cela affectera directement l'opération de synchronisation de la bibliothèque esclave (la bibliothèque esclave n'a pas de bibliothèque principale correspondante pour effectuer les opérations de réplication de données associées) et il n'y a pas d'instance pour prendre en charge le client pour effectuer les opérations d'écriture. .

Passer de la bibliothèque esclave à la bibliothèque principale doit impliquer trois problèmes :

La bibliothèque principale est-elle vraiment en panne ?
Quelle bibliothèque esclave doit être sélectionnée pour basculer vers la bibliothèque maître ?
Comment notifier à la bibliothèque esclave et au client les informations de la nouvelle bibliothèque maître ?

1. Le flux de base du mécanisme sentinelle

Le mécanisme sentinelle est en cours d'exécution lorsque l'instance de bibliothèque maître-esclave est en cours d'exécution. Le principal comportement du mécanisme sentinelle est la surveillance.

1.1 Surveillance sentinelle :

Pendant le processus en cours d'exécution, le processus sentinelle enverra périodiquement des commandes PING à toutes les bibliothèques maître-esclave pour vérifier si elles fonctionnent toujours en ligne. Si la bibliothèque esclave ne répond pas à la commande PING de la sentinelle dans le délai spécifié, la sentinelle la marquera comme "état hors ligne". De même, si la bibliothèque principale ne répond pas à la commande PING de la sentinelle dans le délai spécifié, la sentinelle marquera également la bibliothèque principale comme "état hors ligne", puis lancera le processus de basculement automatique de la bibliothèque principale .

1.2 Changer automatiquement le processus principal de la bibliothèque

Ce processus accomplit d'abord la deuxième tâche de la sentinelle : l'élection du maître. Une fois la bibliothèque principale raccrochée, Sentinel doit sélectionner une instance de bibliothèque esclave parmi de nombreuses bibliothèques esclaves selon certaines règles et l'utiliser comme bibliothèque principale mise à jour. Une fois cette étape terminée, il y aura une nouvelle bibliothèque principale dans le cluster.
Vient ensuite la dernière tâche : les notifications . Lors de l'exécution de la notification de tâche, la sentinelle enverra les informations de la nouvelle bibliothèque principale à toutes les autres bibliothèques esclaves, les laissera exécuter la commande replicaof, établira une connexion avec la nouvelle bibliothèque principale et effectuera la réplication des données. En même temps, Sentinel enverra les informations de connexion de la nouvelle bibliothèque principale au client, lui permettant d'envoyer de nouvelles requêtes à la nouvelle bibliothèque principale.

Parmi ces trois tâches, la tâche de notification est relativement simple, il suffit d'envoyer les informations de la nouvelle bibliothèque principale à la bibliothèque esclave et au client, et de les laisser se connecter à la nouvelle bibliothèque principale, et aucune logique de décision n'est impliquée. Mais dans les deux tâches de surveillance et de sélection du leader, la sentinelle doit prendre deux décisions :

Dans la tâche de surveillance, Sentinel doit décider si la bibliothèque principale est hors ligne
Dans la tâche de sélection du maître, Sentinel décide également quelle instance de bibliothèque esclave choisir comme nouvelle bibliothèque maître.

Comment juger si la base de données principale est hors ligne ?

2. Juger si la base de données principale est hors ligne

Le fait que la base de données principale soit hors ligne est jugé en deux types : "hors ligne subjectif" et "hors ligne objectif".

2.1. Objet hors ligne subjectif

Déconnecté subjectif : le mécanisme sentinelle enverra une commande PING à la bibliothèque maître-esclave pour détecter la connexion réseau entre lui-même et la bibliothèque maître-esclave afin de juger de l'état de l'instance. Si la sentinelle constate que le temps de réponse de la bibliothèque maître-esclave a expiré, elle marquera la bibliothèque maître-esclave comme « subjective hors ligne ».

Mauvaise évaluation

Mais il y aura une situation où la sentinelle a mal jugé que la bibliothèque maître-esclave n'a pas échoué, et la bibliothèque maître n'a pas été déconnectée. Une erreur de jugement se produit généralement lorsque la pression sur le réseau du cluster est élevée, que le réseau est encombré ou que la bibliothèque principale elle-même est sous haute pression .

Une fois que la sentinelle juge que la base de données maître est hors ligne, elle doit effectuer une série d'opérations telles que l'élection du maître et la synchronisation de la base de données maître-esclave, ce qui augmentera les frais de calcul et de communication supplémentaires.

Il est donc nécessaire de réduire les erreurs de jugement.

Comment réduire les erreurs de jugement ?

Introduisez quelques sentinelles supplémentaires pour la négociation et le jugement, c'est-à-dire des grappes sentinelles.

Groupe sentinelle

Cluster Sentinel : généralement déployé en mode cluster composé de plusieurs instances. Introduisez plusieurs instances sentinelles pour le jugement, en évitant la situation où une seule sentinelle juge à tort que la bibliothèque principale est hors ligne en raison d'un réseau médiocre. La probabilité que plusieurs réseaux sentinelles soient instables en même temps est faible, et la probabilité d'erreur de jugement est également faible.

2.2 Objectif hors ligne

Lorsqu'il s'agit de juger si la bibliothèque principale est hors ligne, une sentinelle ne peut pas avoir le dernier mot. La plupart des sentinelles doivent juger que la bibliothèque principale a été "subjectivement hors ligne", et la bibliothèque principale sera marquée comme "objectivement hors ligne". Cette déclaration montre que le bibliothèque principale Se déconnecter est devenu un fait objectif, et le principe de jugement est le suivant : la minorité obéit à la majorité.

Objective offline : Lorsqu'il y a N clusters, lorsqu'il y a N/2+1 clusters qui ont jugé la base de données principale comme "subjectivement offline", la base de données principale peut finalement être jugée comme "objectively offline". Réduisez la surcharge de commutation de bibliothèque maître-esclave causée par une erreur de jugement. (Il existe plusieurs exemples pour porter le jugement de "hors ligne subjectif" de la bibliothèque principale, qui est défini par l'administrateur Redis en toute confiance).

3. Mécanisme de commutation maître-esclave : la commutation maître-esclave sera effectuée lorsque la bibliothèque principale est hors ligne

Comment choisir une nouvelle bibliothèque principale ?

D'une manière générale, le processus de sélection par Sentinel d'une nouvelle bibliothèque principale peut être appelé "sélection + notation". Il s'agit de supprimer les bibliothèques esclaves non qualifiées selon certaines conditions de filtrage dans les bibliothèques esclaves à instances multiples . Ensuite, selon certaines règles , notez les bibliothèques esclaves restantes une par une, et sélectionnez la bibliothèque esclave avec le score le plus élevé comme nouvelle bibliothèque maître.

3.1 Conditions de dépistage

Il est non seulement nécessaire de juger de l'état actuel de la bibliothèque esclave, mais également de son état de connexion réseau précédent . Si le nombre de déconnexions entre la bibliothèque esclave et la bibliothèque maître dépasse le seuil, il y a une raison de détailler que l'état de la connexion réseau de la bibliothèque esclave n'est pas très bon, et il peut être filtré. Bien qu'il fonctionne maintenant, s'il est coupé après un certain temps, le propriétaire doit être réélu, il est donc nécessaire de juger de son état antérieur.

Comment juger ?

Utilisez l'élément de configuration down-after-milliseconds*10. Parmi eux, down-after-milliseconds est le temps maximum que nous considérons pour être déconnecté de la base de données. Si dans les millisecondes d'arrêt après millisecondes, les nœuds maître et esclave ne sont pas connectés au réseau, la base de données esclave est considérée comme déconnectée. Si le temps de déconnexion dépasse 10 fois, on considère que la transition réseau de la bibliothèque esclave n'est pas très bonne et qu'elle n'est pas adaptée à la bibliothèque maître.

3.2 Règles de notation

Il peut être évalué selon trois règles : priorité de la bibliothèque esclave, progression de la copie de la bibliothèque esclave et numéro d'identification de la bibliothèque esclave.

Il doit seulement avoir le score le plus élevé dans un certain tour, alors il est le nouveau maître et le processus de sélection du maître est terminé.S'il n'y a pas de score le plus élevé, le tour suivant aura lieu.

Le premier tour : la bibliothèque esclave avec la priorité esclave la plus élevée a un score plus élevé

Les utilisateurs peuvent définir différentes priorités pour différentes bibliothèques esclaves via l'élément de configuration slave-priority. Par exemple, vous avez deux bibliothèques esclaves avec une grande mémoire

La différence est que vous pouvez définir manuellement une priorité élevée pour les instances disposant d'une mémoire importante. Lors de la sélection du maître, Sentinel donnera des notes élevées à la bibliothèque esclave avec une priorité élevée. S'il existe une bibliothèque esclave avec la priorité la plus élevée, ce sera la nouvelle bibliothèque maître. Si les priorités des bibliothèques esclaves sont les mêmes, la sentinelle commence le deuxième tour de décompte.

Deuxième tour : la bibliothèque esclave avec le degré de synchronisation le plus proche de l'ancienne bibliothèque maître a un score élevé

Si vous choisissez la bibliothèque esclave la plus proche de l'ancienne bibliothèque maître comme bibliothèque maître, la nouvelle bibliothèque maître disposera des données les plus récentes.

Comment juger de la progression de la synchronisation de la bibliothèque esclave et de la bibliothèque maître ? (progrès de la copie)

Lorsque la bibliothèque maître-esclave est synchronisée, il y a un processus de propagation de commande. Dans ce processus, la bibliothèque maître utilisera master-repl-offset pour enregistrer, et la dernière opération d'écriture en cours est en position médiane de repl-backlog- buffer, tandis que la bibliothèque esclave utilisera slave -repl-offset enregistre la progression de la réplication.

Nous devons donc trouver la bibliothèque esclave la plus proche de master-repl-offset et slave-repl-offset. Si le score est élevé, elle sera sélectionnée comme nouvelle bibliothèque principale. Si le décalage esclave-repl est le même, le prochain tour de notation sera effectué.

Comme le montre la figure ci-dessous, le master_repl_offset de l'ancienne bibliothèque maître est 1000 et le slave_repl_offset des bibliothèques esclaves 1, 2 et 3 sont respectivement 950, 990 et 900. Ensuite, la bibliothèque esclave 2 doit être sélectionnée comme nouvelle bibliothèque maîtresse.

Le troisième tour : celui avec le numéro d'identification le plus petit obtient le score le plus élevé du groupe

Chaque instance aura un identifiant, qui est similaire au numéro de la bibliothèque esclave. Lorsque Redis sélectionne le maître, il y a une règle : à priorité et progression de réplication identiques, plus l'ID est petit, plus le score est élevé.

3.3 Résumé de la commutation maître-esclave

Tout d'abord, le mécanisme sentinelle filtrera certaines bibliothèques esclaves qui ne répondent pas aux exigences en fonction de l'état en ligne et de l'état du réseau. Ensuite, notez la bibliothèque esclave en fonction de la priorité, de la progression de la réplication et de la taille de l'ID, et celle avec le score le plus élevé est sélectionnée comme nouvelle bibliothèque maître.

4. Résumé du mécanisme sentinelle

La synchronisation des données du cluster maître-esclave garantit la fiabilité des données. Lorsque la bibliothèque principale tombe en panne, la commutation automatique maître-esclave est le support clé pour un service ininterrompu.

Le mécanisme sentinelle de Redis remplit automatiquement les trois fonctions suivantes, réalisant ainsi la commutation automatique de la bibliothèque maître-esclave, ce qui peut réduire les frais généraux d'exploitation et de maintenance du cluster Redis :

Surveillez l'état de fonctionnement de la bibliothèque principale et jugez si la bibliothèque principale est objectivement hors ligne ;
Une fois que la bibliothèque principale est objectivement hors ligne, sélectionnez une nouvelle bibliothèque principale ;
Une fois la nouvelle bibliothèque maître sélectionnée, la bibliothèque esclave et le client sont notifiés.

Afin de réduire le taux d'erreurs de jugement, dans les applications pratiques, le mécanisme sentinelle est généralement déployé de manière multi-instance. Plusieurs instances sentinelles utilisent le principe "la minorité obéit à la majorité" pour juger si la base de données principale est objectivement hors ligne. De manière générale, nous pouvons déployer trois sentinelles. Si deux sentinelles déterminent que la bibliothèque principale est "subjectivement hors ligne", le processus de commutation peut être lancé. Bien sûr, si vous souhaitez améliorer encore la précision du jugement, vous pouvez également augmenter le nombre de sentinelles de manière appropriée, par exemple, utiliser cinq sentinelles.

Que dois-je faire si une instance du cluster sentinelle est en panne ? Cela affectera-t-il le jugement de l'état de la base de données principale et l'élection du maître ?

En termes simples, la conclusion : lorsqu'il y a des nœuds défectueux, tant que la plupart des nœuds du cluster sont dans un état normal, le cluster peut toujours fournir des services au monde extérieur.

La plupart des instances du cluster sentinelle parviennent à un consensus, et après avoir jugé que la bibliothèque principale est "objectivement hors ligne", quelle instance effectuera le basculement maître-esclave ?

Une fois que le cluster sentinelle aura jugé que la bibliothèque principale est "subjectivement hors ligne", il élira un "chef sentinelle", puis il terminera le commutateur maître-esclave dans l'ensemble du processus.

Pendant le processus de commutation maître-esclave de Sentinel, le client peut-il normalement effectuer l'opération de requête ?

Si le client utilise la séparation lecture-écriture, la demande de lecture peut être exécutée normalement sur la bibliothèque esclave sans être affectée. Cependant, étant donné que la bibliothèque principale a été raccrochée à ce moment et que la sentinelle n'a pas encore sélectionné de nouvelle bibliothèque principale, la demande d'écriture échouera pendant cette période et la durée de l'échec = l'heure à laquelle la sentinelle commute le maître -esclave + le client perçoit la nouvelle heure de la bibliothèque principale.

Si vous ne voulez pas que l'entreprise soit au courant de l'exception, le client peut uniquement mettre en cache les demandes ayant échoué en écriture ou les écrire dans le middleware de file d'attente de messages, et envoyer ces demandes d'écriture à la nouvelle bibliothèque principale après que la sentinelle a changé de maître. -esclave. Ce scénario convient uniquement aux entreprises qui ne sont pas sensibles à la valeur de retour de la demande d'écriture, et doit également être adapté par la couche métier. De plus, si le commutateur maître-esclave prend trop de temps, il sera également trop de demandes d'écriture dans le cache du middleware client ou de la file d'attente de messages. Il faut plus de temps pour rejouer ces demandes une fois terminées.

La sentinelle détecte pendant combien de temps la bibliothèque principale ne répond pas avant de promouvoir la bibliothèque esclave vers la nouvelle bibliothèque principale.Ce temps est paramétrable (paramètre down-after-milliseconds). Plus le temps de configuration est court, plus la sentinelle est sensible. Le cluster sentinelle initiera une commutation maître-esclave si la bibliothèque principale ne peut pas être connectée dans un court laps de temps. Cette configuration est susceptible de provoquer une commutation inutile en raison de la congestion du réseau, mais la bibliothèque principale est normale Bien sûr, lorsque la bibliothèque principale échoue vraiment, en raison du basculement opportun, l'impact sur l'entreprise est minime. Si le temps de configuration est plus long, plus la sentinelle est conservatrice, ce qui peut réduire la probabilité d'erreur de jugement de la part de la sentinelle. Cependant, lorsque la bibliothèque principale tombe en panne, le temps d'échec d'écriture métier sera plus long et la quantité de requêtes d'écriture en cache les données vont augmenter.

2. La sentinelle raccroche

Si une instance sentinelle échoue pendant l'exécution, la bibliothèque maître-esclave peut-elle toujours commuter normalement ?

En fait, une fois que plusieurs instances forment un cluster sentinelle, même si une instance sentinelle échoue et raccroche, d'autres sentinelles peuvent continuer à coopérer pour terminer le travail de commutation de la bibliothèque principale, notamment en déterminant si la bibliothèque principale est hors ligne et en sélectionnant une nouvelle bibliothèque principale. bibliothèque et les notifications des bibliothèques et des clients.

Si vous avez déployé un cluster sentinelle, vous saurez que lors de la configuration des informations sentinelles, nous n'avons qu'à utiliser l'élément de configuration suivant pour définir l'adresse IP et le port principaux, et ne pas configurer les informations de connexion des autres sentinelles.

moniteur sentinelle <nom-maître> <ip> <port-redis> <quorum>

Puisque les sentinelles ne connaissent pas les adresses des autres, comment forment-elles un cluster sentinelle ?

1. Composition du cluster sentinelle basée sur le mécanisme pub/sub

La raison pour laquelle les sentinelles peuvent être découvertes les unes par les autres : le mécanisme pub/sub fourni par Redis (mécanisme de publication/abonnement)

1.1 Les sentinelles sont découvertes les unes par les autres :

Tant que la sentinelle a établi une connexion avec la bibliothèque principale, elle peut publier des informations sur la bibliothèque principale et publier ses propres informations de connexion (ip et numéro de port). En parallèle, vous pouvez également vous abonner aux informations de la bibliothèque principale pour obtenir des informations de connexion publiées par d'autres Sentinelles. Lorsque plusieurs sentinelles publient et s'abonnent sur la bibliothèque principale, elles connaissent l'adresse IP et le numéro de port de l'autre.

En plus des instances sentinelles, les applications écrites par nous-mêmes peuvent également publier et s'abonner à des messages via Redis.

Comment Redis différencie-t-il les différentes applications ?

Redis chemin à travers les canaux. Classer et gérer les messages pour distinguer les différents messages d'application. Un canal est en fait un type de message. Lorsque les types de message sont identiques, ils appartiennent à un canal. Seules les applications abonnées au même canal peuvent échanger des informations via des messages publiés.

Dans le cluster maître-esclave, la bibliothèque maître dispose d'un canal "__sentinel__:hello", et différentes sentinelles peuvent se découvrir et communiquer entre elles en l'implémentant.

1.2 Instructions pour l'échange de messages Sentinel :

Par exemple : Dans la figure ci-dessous, Sentinel 1 publie sa propre adresse IP (17216.19.3) et son port 26579) sur le canal "_sentinel_:hello", et Sentinel 2 et 3 s'abonnent à ce canal. Ensuite, à ce moment, Sentinel 2 et 3 peuvent obtenir directement l'adresse IP et le numéro de port de Sentinel 1 à partir de ce canal.

Ensuite, les Sentinelles 2 et 3 peuvent établir une connexion réseau avec Sentinelle 1. De cette manière, les Sentinelles 2 et 3 peuvent également établir une connexion réseau, de sorte qu'un cluster Sentinel est formé. Ils peuvent communiquer entre eux via des connexions réseau, comme juger et négocier si la bibliothèque principale est hors ligne

En plus d'établir des connexions entre elles pour former un cluster, les Sentinelles doivent également établir des connexions avec des bibliothèques esclaves. Parce que dans la tâche de surveillance sentinelle, la sentinelle doit faire un jugement de pulsation sur la bibliothèque maître-esclave, et une fois le commutateur de bibliothèque maître-esclave terminé, elle doit également notifier la bibliothèque esclave pour les synchroniser avec la nouvelle bibliothèque maître.

Comment Sentinel se connecte-t-il au résumé de la bibliothèque esclave ? Comment connaitre l'adresse IP et le port de la librairie esclave ?

1.3 Sentinel établit une connexion avec la bibliothèque esclave : commande INFO

Lorsque la sentinelle envoie une commande INFO à la bibliothèque principale, la bibliothèque principale renverra la liste des bibliothèques esclaves à la sentinelle après avoir reçu la commande. Une fois que Sentinel reçoit les informations de connexion de la liste des bibliothèques esclaves, il établit une connexion avec chaque bibliothèque esclave et surveille en permanence la bibliothèque esclave sur cette connexion.

Grâce au mécanisme pub/sub, des grappes sentinelles sont établies entre les sentinelles, et les informations de connexion de la bibliothèque esclave sont obtenues en envoyant la commande INFO, et la sentinelle établit une connexion avec la bibliothèque esclave pour la surveillance. Une fois la bibliothèque maître-esclave commutée, le client doit connaître les informations de connexion de la nouvelle bibliothèque maître avant d'envoyer des informations à la nouvelle bibliothèque maître. Par conséquent, la sentinelle doit également terminer la tâche d'informer le client des nouvelles informations de la bibliothèque principale.

Lors de l'utilisation réelle de Sentinel, nous rencontrons parfois un problème : comment surveiller le processus de commutation maître-esclave de Sentinel côté client ? Par exemple, à quelle étape la commutation maître-esclave a-t-elle progressé ? Il s'agit en fait d'une exigence, le client Il est possible d'obtenir divers événements qui se produisent au cours du processus de surveillance, de sélection du maître et de commutation du cluster sentinelle.

1.4 Synchronisation des informations entre la sentinelle et le client

1.5 Notification des événements client basée sur le mécanisme pub/sub

En substance, Sentinel est une instance Redis fonctionnant dans un mode spécifique, mais elle ne termine pas l'opération de demande de service, mais effectue uniquement les tâches de surveillance, d'élection du maître et de notification. Ainsi, chaque instance sentinelle fournit également un mécanisme pub/sub, les clients peuvent s'abonner aux messages de sentinel . Il existe de nombreux canaux d'abonnement aux messages fournis par Sentinel, et différents canaux contiennent différents événements clés pendant le processus de commutation de la bibliothèque maître-esclave.

Événements communs :

événement	chaîne associée
Événement hors ligne de la bibliothèque principale	+sdown (l'instance passe à l'état "subjective offline")
	-sdown (l'instance sort de l'état "subjective offline")
	+odown (l'instance passe à l'état "objectivement hors ligne")
	-odown (l'instance sort de l'état "objectivement hors ligne")
Evénement de reconfiguration de l'esclave	+slave-reconf-sent (sentry envoie la commande SLACEOF pour reconfigurer la bibliothèque esclave)
	+slave-reconf-inprog (configurer la nouvelle bibliothèque principale à partir de la bibliothèque, mais pas encore synchronisée)
	+slave-reconf-done (configurer la nouvelle bibliothèque principale à partir de la bibliothèque et terminer la synchronisation avec la nouvelle bibliothèque principale)
Nouveau commutateur principal de la bibliothèque	+switch-master (changement d'adresse de la bibliothèque principale)

Connaissant ces canaux, les clients peuvent s'abonner aux messages de Sentry. Les étapes de fonctionnement spécifiques sont qu'après que le client a lu le fichier de configuration de Sentinel, il peut obtenir l'adresse et le port de Sentinel et établir une connexion réseau avec Sentinel. Ensuite, vous pouvez exécuter la commande d'abonnement sur le client pour obtenir différents messages d'événement.

Par exemple, vous pouvez exécuter la commande suivante pour vous abonner à "l'événement où toutes les instances entrent dans l'état hors ligne objectif" :

abonnez-vous + odown

Abonnez-vous à toutes les chaînes

PSABONNEZ-VOUS *

Lorsque la sentinelle sélectionne la nouvelle bibliothèque maître, le client verra l'événement switch-master suivant. Cet événement indique que la bibliothèque principale a été changée et que l'adresse IP et les informations de port de la nouvelle bibliothèque principale sont déjà disponibles. À ce stade, le client peut utiliser l'adresse et le port de la nouvelle bibliothèque principale pour communiquer.

switch-master <nom du maître> <oldip><oldport> <newport>

Grâce à la notification d'événements, le client peut non seulement obtenir les informations de connexion de la nouvelle bibliothèque maître après le basculement maître-esclave, mais également surveiller et obtenir divers événements importants qui se produisent pendant le basculement maître-esclave. De cette manière, le client peut savoir à quelle étape le maître-esclave bascule, ce qui aide à comprendre la vitesse de commutation.

Résumé : Avec le mécanisme pub/sub, Sentry peut établir des connexions avec des bibliothèques esclaves, entre Sentinels et Sentinels, et entre Sentinels et clients. En jugeant que la bibliothèque principale est hors ligne, les trois tâches de surveillance, de sélection principale et de notification basées sur le cluster sentinelle peuvent fondamentalement fonctionner normalement.

Après la panne maître-esclave, il y a plusieurs instances dans le cluster, comment déterminer quelle sentinelle effectuera le véritable basculement maître-esclave ?

2. Quelle sentinelle effectue la commutation maître-esclave ?

En fait, le processus de commutation maître-esclave par lequel la sentinelle est en fait un processus "d'arbitrage de vote" tout comme l'élection du maître.

2.1 À partir du processus principal d'élection Sentinel :

Toute instance enverra la commande is-master-down-by-addr à d'autres instances tant qu'elle jugera que la bibliothèque principale est "subjectivement hors ligne". Ensuite, les autres instances répondront par Y ou N selon leur lien avec la bibliothèque principale, Y équivaut à un vote favorable et N équivaut à un vote négatif.

Une fois qu'une sentinelle a obtenu le nombre de votes oui requis pour l'arbitrage, elle peut marquer la bibliothèque principale comme "objectivement hors ligne". Le nombre requis de votes positifs est défini via l'élément de configuration de quorum dans le fichier de configuration sentinelle. Par exemple, il y a maintenant 5 sentinelles et la configuration du quorum est de 3. Ensuite, une sentinelle a besoin de 3 votes positifs et la bibliothèque principale peut être marquée comme "objectivement hors ligne". Les 3 votes oui incluent le vote oui de la sentinelle et les deux autres votes oui de la sentinelle.

2.2 La sentinelle élit le processus Leader: Leader Election

À ce stade, la sentinelle peut envoyer des commandes à d'autres sentinelles, indiquant qu'elle souhaite effectuer la commutation maître-esclave par elle-même, et laisser toutes les autres sentinelles voter. Ce processus de vote s'appelle "l'élection du chef". Étant donné que la sentinelle qui effectue finalement la commutation maître-esclave est appelée le leader, le processus de vote consiste à déterminer le leader.

Lors du processus de vote, toute Sentinelle qui souhaite devenir Leader doit remplir deux conditions : premièrement, obtenir plus de la moitié des votes favorables ; deuxièmement, le nombre de votes qu'il obtient doit être supérieur ou égal à la valeur du quorum dans le fichier de configuration sentinelle. Prenons 3 sentinelles comme exemple, en supposant que le quorum est fixé à 2 à ce moment, alors toute sentinelle qui veut devenir leader n'a besoin que de 2 votes oui.

Plus précisément expliqué à travers la figure suivante :

A T1, S1 juge que la base de données principale est "objectivement hors ligne". S'il veut devenir leader, il vote d'abord pour lui-même, puis envoie respectivement des commandes à S2 et S3, indiquant qu'il veut devenir leader.

À T2, S3 juge que la base de données principale est "objectivement hors ligne", et il veut également devenir un leader, donc il vote d'abord pour lui-même, puis envoie des commandes à S1 et S2 respectivement, indiquant qu'il veut devenir un leader.

A l'instant T3, S1 reçoit la demande de vote Leader de S3. Parce que S1 a voté Y pour lui-même, il ne peut plus voter pour d'autres sentinelles, donc S1 répond N pour exprimer son désaccord. En même temps, S2 reçoit la demande de vote Leader envoyée par S3 à T2. Parce que S2 n'a pas voté auparavant, il répondra Y à la première sentinelle qui a envoyé une demande de vote, et répondra N à la sentinelle qui a envoyé une demande de vote plus tard. Par conséquent, à T3, S2 répond à S3 et accepte que S3 devienne le leader .

A T4, S2 reçoit la commande de vote envoyée par S1 à T1. Étant donné que S2 a accepté la demande de vote de S3 à T3, à ce moment, S2 répond N à S1, exprimant sa désapprobation à ce que S1 devienne le leader. Cela se produit parce que le trafic réseau entre S3 et S2 est normal, mais le trafic réseau entre S1 et S2 peut simplement être encombré, ce qui ralentit la transmission de la demande de vote.

Enfin, au temps T5, S1 obtient une voix Y de lui-même et une voix N de S2. En plus de son propre vote Y, S3 a également reçu un vote Y de S2. À ce moment, S3 a non seulement obtenu plus de la moitié des votes du Leader, mais a également atteint la valeur de quorum prédéfinie (le quorum est de 2), il est donc finalement devenu le Leader. Ensuite, S3 commencera à effectuer l'opération de sélection principale et, une fois la nouvelle bibliothèque principale sélectionnée, il informera les autres bibliothèques esclaves et les clients des nouvelles informations de la bibliothèque principale.

Si S3 n'obtient pas 2 votes Y, alors ce tour de scrutin ne produira pas de Leader. Le cluster Sentinel attendra un certain temps (c'est-à-dire le double du délai d'expiration du basculement Sentinel) avant d'être réélu . En effet, le succès du vote du cluster sentinelle dépend en grande partie de la propagation normale sur le réseau des commandes d'élection. Si la pression sur le réseau est élevée ou s'il y a une congestion à court terme, il se peut qu'aucune sentinelle n'obtienne plus de la moitié des votes favorables. Par conséquent, attendez que la congestion du réseau s'améliore avant de voter, et la probabilité de succès augmentera.

A noter que s'il n'y a que 2 instances dans le cluster sentinelle, à ce moment, si une sentinelle veut devenir leader, elle doit obtenir 2 votes au lieu de 1 vote. Par conséquent, si une sentinelle raccroche, le cluster à ce moment ne peut pas effectuer de commutation de bibliothèque maître-esclave. Par conséquent, nous configurons généralement au moins 3 instances Sentinel. Ceci est très important et vous ne pouvez pas l'ignorer dans les applications pratiques.

Pourquoi les Sentinelles ne votent pas pour elles-mêmes en même temps ?

Pour que S1, S2 et S3 votent avec eux-mêmes en même temps, il est nécessaire que ces trois sentinelles déterminent que la bibliothèque principale est objectivement hors ligne en même temps. Cependant, les connexions réseau et les pressions système des différents Sentinels ne sont pas exactement les mêmes, et l'heure de réception du message de négociation hors ligne peut également être différente.Par conséquent, la probabilité qu'ils portent un jugement hors ligne objectif sur la base de données principale en même temps est relativement faible et il existe généralement une relation de séquence. L'exemple dans l'article est que S1 et S3 sont jugés en premier, et S2 n'a pas été jugé.

Les opérations telles que la vérification de l'état en ligne de la bibliothèque maître-esclave par la sentinelle sont une sorte d'événement temporel, complété par un temporisateur.Généralement, ces événements sont exécutés toutes les 100ms. Un petit décalage temporel aléatoire sera ajouté au cycle d'exécution de la minuterie de chaque sentinelle. Le but est de décaler légèrement le temps nécessaire à chaque sentinelle pour effectuer les opérations ci-dessus, et également de les empêcher de déterminer simultanément que la bibliothèque principale est hors ligne et élire en même temps.

Redis a 1 maître et 4 esclaves, 5 sentinelles et le quorum des sentinelles est de 2. Si 3 sentinelles échouent, lorsque la base de données principale est en panne, les sentinelles peuvent-elles juger que la base de données principale est "objectivement hors ligne" ? Peut-il basculer automatiquement ?

1. Le cluster sentinelle peut déterminer que la base de données principale est "subjectivement hors ligne" . Comme quorum=2, lorsqu'une sentinelle juge que la base de données principale est "subjectivement déconnectée", elle obtiendra le même résultat après avoir interrogé une autre sentinelle. Le cluster sentinelle peut déterminer que la bibliothèque principale est "objectivement déconnectée".

2. Cependant, Sentinel ne peut pas terminer la commutation maître-esclave . Une fois que la sentinelle a marqué la base de données principale "objectivement hors ligne", lors de l'élection du "chef de la sentinelle", une sentinelle doit obtenir plus de la majorité des voix (5/2 + 1 = 3 voix). Mais actuellement, il n'y a que 2 sentinelles en vie.Peu importe comment vous votez, une sentinelle ne peut obtenir que 2 votes au maximum, et elle n'atteindra jamais le résultat d'une majorité de votes.

Est-il préférable d'avoir plus d'instances sentinelles ?

Non, nous avons également vu que la sentinelle doit communiquer avec d'autres nœuds et échanger des informations lors du jugement "subjectif hors ligne" et de l'élection du "chef de la sentinelle". Plus il y a d'instances sentinelles, plus il y a de temps de communication, et lors du déploiement de plusieurs sentinelles, elles seront être répartis sur différentes machines. Plus il y a de nœuds, plus le risque de panne de la machine est grand. Ces problèmes vont affecter la communication et l'élection des sentinelles. Lorsqu'il y a un problème, cela signifie que le temps d'élection sera plus long. , le le temps de commutation maître-esclave devient plus long.
Plus il y a d'instances sentinelles, plus le taux d'erreurs de jugement sera faible. Cependant, lorsque la bibliothèque principale est déterminée comme étant hors ligne et que le responsable est élu, l'instance doit obtenir plus de votes et le temps d'attente pour que toutes les sentinelles votent peut également augmenter. Le temps de basculement depuis la bibliothèque deviendra également plus long et le client accumulera facilement plus d'opérations de demande, ce qui peut provoquer un débordement de demande client, entraînant une perte de demande. Si la couche de gestion a des exigences de temps de réponse pour les opérations Redis, une alarme de dépassement de délai peut se produire car la nouvelle bibliothèque principale n'a pas été sélectionnée et la nouvelle opération ne peut pas être exécutée.
Une fois que le temps d'arrêt après millisecondes a augmenté, cela peut conduire à une telle situation : la bibliothèque principale est en fait tombée en panne, mais la sentinelle a mis beaucoup de temps à juger, ce qui affectera la disponibilité de Redis pour les entreprises.

Est-il avantageux de réduire les faux positifs en augmentant la valeur down-after-milliseconds ?

C'est avantageux. Augmentez correctement la valeur d'arrêt après millisecondes. Lorsqu'il y a des fluctuations à court terme dans le réseau entre la sentinelle et la bibliothèque principale, la probabilité d'erreur de jugement peut être réduite . Cependant, l'augmentation de la valeur d'arrêt après millisecondes signifie également que le temps de basculement maître-esclave sera plus long, et plus l'impact sur l'entreprise est long, nous devons le peser en fonction du scénario réel et fixer un seuil raisonnable.

3. Résumé : Le mécanisme clé de la sentinelle (la sentinelle contacte la sentinelle invitée maître-esclave et le chef choisit le maître)

Lorsque nous résolvons un problème système, nous introduisons un nouveau mécanisme ou concevons une couche de nouvelles fonctions.Le contenu principal de la sentinelle : afin de réaliser le commutateur maître-esclave, nous introduisons la sentinelle ; afin d'éviter la défaillance de le commutateur maître-esclave après la défaillance d'une seule sentinelle, et Afin de réduire le taux d'erreurs d'appréciation, un cluster sentinelle est introduit ; le cluster sentinelle a besoin de certains mécanismes pour soutenir son fonctionnement normal.

3.1 Ces mécanismes clés du cluster sentinelle :

Processus de formation de grappes sentinelles basé sur le mécanisme pub/sub ;
Liste d'esclaves basée sur la commande INFO, qui peut aider Sentinel et la bibliothèque esclave à établir une connexion ;
Basé sur la propre fonctionnalité pub/sub de Sentinel, cela permet la notification d'événements entre les clients et Sentinel.

Pour la commutation maître-esclave, bien sûr, aucune sentinelle ne peut l'exécuter si elle le souhaite, sinon elle sera gâchée. Par conséquent, cela nécessite que le cluster sentinelle élise un leader après avoir jugé que la bibliothèque principale est "objectivement hors ligne" par arbitrage de vote, et il est responsable de la véritable commutation maître-esclave, c'est-à-dire qu'il complète la sélection de la nouvelle bibliothèque principale. et avertit les bibliothèques esclaves et les clients.

Enfin, j'aimerais partager une autre expérience avec vous : assurez-vous que les configurations de toutes les instances sentinelles sont cohérentes, en particulier la valeur de jugement de down-after-milliseconds pour subjectif offline . Cette valeur est configurée de manière incohérente sur différentes instances Sentinel. Par conséquent, le cluster Sentinel n'a pas atteint un consensus sur la bibliothèque principale défectueuse et n'a pas changé de bibliothèque principale à temps. Le résultat final est que le service de cluster est instable. Par conséquent, vous ne devez pas ignorer cette expérience apparemment simple.

3. Résumé de toutes les Sentinelles

1. Comment Sentinel se connecte-t-il à la bibliothèque principale

Sentinel est directement associé à la bibliothèque principale, défini manuellement, vous pouvez définir plusieurs sentinelles

2. Comment la sentinelle envoie-t-elle des messages à la bibliothèque esclave ?

La sentinelle envoie la commande info à la bibliothèque maître, la bibliothèque maître renvoie la collection esclave de la bibliothèque esclave, établit une connexion avec la bibliothèque esclave et envoie les informations de la nouvelle bibliothèque maître à la bibliothèque esclave

3. Comment la sentinelle contacte-t-elle le client ?

Le client s'abonne à un canal de Sentinel, qui est le maître du canal, lit le fichier de configuration de la sentinelle, obtient l'adresse IP et le numéro de port, établit une connexion avec la sentinelle, s'abonne aux informations après la connexion, obtient les informations de la bibliothèque maître et communique avec la bibliothèque maître La bibliothèque établit une connexion

Interprétation détaillée du mécanisme Redis Sentinel

1. Interprétation de base du mécanisme sentinelle