Introduction à Redis Sentinel
Le processus Sentinel est utilisé pour surveiller l'état de fonctionnement du serveur maître dans le cluster Redis sur le maître. serveur Lorsqu'une panne survient, les serveurs Maître et Esclave peuvent être commutés pour assurer une haute disponibilité du système. Il a été intégré dans la version redis 2.6+. Le mode sentinelle de Redis s'est stabilisé depuis la version 2.8. Généralement, il est recommandé d'utiliser Redis version 2.8 ou ultérieure dans un environnement de production. Sentinel est un système distribué. Vous pouvez exécuter plusieurs processus sentinelles dans une architecture. Ces processus utilisent des protocoles de potins pour recevoir des informations indiquant si le serveur maître est hors ligne et utilisent des protocoles de vote (protocoles d'accord) pour décider d'effectuer un basculement automatique et vers quel esclave. choisir comme nouveau Maître. Chaque processus Sentinel enverra régulièrement des messages aux autres Sentinels, maître et esclave pour confirmer si l'autre partie est « vivante ». S'il s'avère que l'autre partie n'a pas reçu de réponse dans le délai de configuration spécifié (configurable), il le fera. temporairement Penser que l'autre partie est hors ligne est ce qu'on appelle la « croyance subjective qu'elle est en panne ». Le nom anglais est : Subjective Down, ou SDOWN en abrégé. S’il y a un temps d’arrêt subjectif, il doit y avoir un temps d’arrêt objectif. Lorsque la plupart des processus Sentinel du « Groupe Sentinel » effectuent des jugements SDOWN sur le serveur maître et communiquent entre eux via la commande SENTINEL is-master-down-by-addr, le serveur maître est jugé hors ligne de cette manière. « objective downtime », le nom anglais est : Objectivement Down, ou ODOWN en abrégé. Grâce à un certain algorithme de vote, l'un des nœuds de serveur esclave restants est sélectionné pour être promu au nœud de serveur maître, puis les configurations pertinentes sont automatiquement modifiées et le basculement est activé.
Bien que sentinel ait un fichier exécutable distinct redis-sentinel, il s'agit en fait d'un simple serveur Redis fonctionnant dans un mode spécial. Vous pouvez démarrer un serveur Redis normal en donnant l'option - -sentinel pour démarrer Sentinel. de sentinelle sont très similaires au gardien de zoo.
Les clusters Sentinel communiqueront entre eux, communiqueront l'état des nœuds Redis, porteront les jugements correspondants et les traiteront. Le statut hors ligne subjectif et le statut hors ligne objectif sont ici des statuts plus importants, ils déterminent s'il est possible d'effectuer un basculement. Cela se fait en vous abonnant aux informations de canal spécifiées et en informant l'administrateur en cas de panne du serveur. Le client peut considérer Sentinel comme un serveur Redis qui fournit uniquement des fonctions d'abonnement. Vous ne pouvez pas utiliser la commande PUBLISH pour envoyer des messages à ce serveur. Vous pouvez utiliser la commande SUBSCRIBE ou la commande PSUBSCRIBE pour obtenir les rappels d'événements correspondants en vous abonnant à un canal donné. Une chaîne peut recevoir des événements portant le même nom que la chaîne. Par exemple, un canal nommé +sdown peut recevoir des événements lorsque toutes les instances entrent dans l'état subjectif hors ligne (SDOWN).
Le rôle du processus Sentinel :
1. Surveillance : Sentinel vérifiera en permanence si votre maître et votre esclave fonctionnent normalement.
2. Notification : lorsqu'un problème survient dans un nœud Redis surveillé, la sentinelle peut envoyer des notifications à l'administrateur ou à d'autres applications via l'API.
3. Basculement automatique : lorsqu'un maître ne fonctionne pas correctement, la sentinelle lancera une opération de basculement automatique. Elle mettra à niveau l'un des esclaves du maître défaillant vers un nouveau maître et laissera les autres esclaves s'installer. le maître défaillant change pour copier le nouveau maître ; lorsque le client essaie de se connecter au maître défaillant, le cluster renverra également l'adresse du nouveau maître au client, afin que le cluster puisse utiliser le maître actuel pour remplacer le maître défaillant. . Une fois les serveurs maître et esclave commutés, le contenu des fichiers de configuration redis.conf du maître, redis.conf et sentinel.conf de l'esclave changera en conséquence, c'est-à-dire qu'il y aura une ligne supplémentaire de slaveof dans la configuration redis.conf du maître. Configuration, la cible de surveillance de sentinel.conf sera modifiée en conséquence
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!