Redis est un système de stockage de structure de données en mémoire open source qui peut être utilisé comme base de données, cache et middleware de messagerie. Cependant, en tant que service unique, Redis peut entraîner une indisponibilité du service en cas de panne matérielle ou de problèmes de réseau. Pour résoudre ce problème, Redis propose le mode sentinelle, une solution haute disponibilité.
Dans ce blog, nous allons approfondir le modèle Sentinel de Redis. Nous présenterons d’abord les concepts de base du mode sentinelle, notamment le nœud maître, le nœud esclave et le nœud sentinelle. Ensuite, nous analyserons en détail les principaux processus du mode Sentinel, y compris le hors-ligne subjectif, le hors-ligne objectif, l'élection du leader et le basculement.
Que vous soyez un débutant sur Redis ou un développeur expérimenté, je pense que ce blog peut vous aider à mieux comprendre et utiliser le mode sentinelle de Redis. commençons!
Annuaire d'articles
1. Introduction au mode Redis Sentinel
1.1. Présentation du mode Redis Sentinel
Le mode sentinelle Redis est une solution haute disponibilité fournie par Redis. Il surveille l'état d'exécution du serveur maître Redis et des serveurs esclaves à l'aide de nœuds sentinelles. Lorsque le serveur maître tombe en panne, la sentinelle peut automatiquement promouvoir un serveur esclave vers le nouveau serveur maître pour effectuer le basculement.
Voici les principales fonctionnalités du mode Redis Sentinel :
- Surveillance : Sentinel vérifiera régulièrement si le serveur maître et les serveurs esclaves fonctionnent normalement, notamment s'ils peuvent répondre normalement aux demandes des clients et si la réplication des données entre les serveurs maître et esclave est normale.
- Notification : lorsque Sentinel découvre que le serveur maître est en panne, il peut envoyer des notifications à l'administrateur via l'API.
- Basculement automatique : lorsque le serveur maître tombe en panne, Sentinel élira automatiquement un nouveau serveur maître parmi les serveurs esclaves et laissera les autres serveurs esclaves commencer à répliquer le nouveau serveur maître.
- Fournisseur de configuration : les clients peuvent demander à Sentinel quel serveur est le maître actuel. De cette façon, même en cas de basculement, le client peut trouver le bon serveur principal.
1.2. Réplication maître-esclave Redis et mode sentinelle
Le mode de réplication maître-esclave est un moyen courant d'améliorer la redondance des données et les performances de lecture dans Redis, mais il présente également certains inconvénients :
- Problème de point de défaillance unique : en mode de réplication maître-esclave, toutes les opérations d'écriture sont effectuées sur le serveur maître. Si le serveur maître tombe en panne, l'ensemble du service Redis ne pourra pas traiter les demandes d'écriture.
- Récupération manuelle après panne : lorsque le serveur maître tombe en panne, vous devez promouvoir manuellement un serveur esclave vers le nouveau serveur maître et modifier la configuration de l'application pour qu'elle pointe vers le nouveau serveur maître. Ce processus peut prendre un certain temps et entraîner une interruption du service.
- Problème de cohérence des données : lors du processus de réplication des données du serveur maître vers le serveur esclave, si un problème de réseau survient ou si le serveur esclave tombe en panne, les données sur le serveur maître et le serveur esclave peuvent être incohérentes.
Le mode sentinelle Redis est conçu pour résoudre ces problèmes :
- Basculement automatique : le mode Sentinelle peut détecter automatiquement l'état du serveur maître. Lorsque le serveur maître tombe en panne, la sentinelle élira automatiquement un nouveau serveur maître parmi les serveurs esclaves et laissera les autres serveurs esclaves commencer à répliquer le nouveau serveur maître. Ce processus est automatique et ne nécessite aucune intervention manuelle, ce qui peut réduire le temps d'interruption de service provoqué par une panne du serveur principal ;
- Évitez les points de défaillance uniques : le mode Sentinel évite les points de défaillance uniques grâce au basculement automatique. Même si le serveur principal tombe en panne, le service Redis peut toujours continuer à traiter les demandes d'écriture ;
- Notification : Sentinel peut envoyer les résultats du basculement au client ;
- Fournir une fonction de découverte de services : Sentinel fournit également une fonction de découverte de services. Le client peut demander à Sentinel quel est le serveur maître actuel, de sorte que même en cas de basculement, le client puisse trouver le bon serveur maître.
1.3. Principaux rôles du mode sentinelle Redis
En mode sentinelle Redis, il y a trois rôles principaux :
- Maître : Le nœud maître est le principal fournisseur de services Redis. Il gère toutes les opérations d'écriture et copie les données sur les nœuds esclaves. Dans des circonstances normales, toutes les opérations de lecture et d'écriture sont gérées par le nœud maître ;
- Esclave : le nœud esclave est la sauvegarde du nœud maître. Il copie les données du nœud maître et peut gérer les opérations de lecture. Lorsque le nœud maître tombe en panne, le nœud esclave peut être promu au nouveau nœud maître ;
- Nœud sentinelle (Sentinel) : le nœud sentinelle est la clé de la haute disponibilité de Redis. Il surveille l'état d'exécution du nœud maître et des nœuds esclaves. Lorsque le nœud maître tombe en panne, le nœud sentinelle basculera, élira un nouveau nœud maître et reconfigurera. le nœud esclave.
En mode sentinelle, il peut y avoir plusieurs nœuds maîtres, nœuds esclaves et nœuds sentinelles pour former un service Redis distribué et hautement disponible.
2. Principe du mode sentinelle Redis
Le mode Sentinelle utilise des nœuds sentinelles pour effectuer la surveillance, la mise hors ligne et le basculement des nœuds de données.
2.1. Surveillance du timing du mode sentinelle Redis
Le nœud sentinelle vérifiera régulièrement l'état de fonctionnement du serveur maître et de tous les serveurs esclaves, notamment s'ils sont en ligne, s'ils peuvent répondre normalement aux demandes, si la réplication des données maître-esclave est normale, etc.
Voici les principales étapes d’une surveillance planifiée en mode sentinelle :
- Toutes les 1 seconde (par défaut), chaque nœud Sentinel envoie une commande PING au nœud maître, aux nœuds esclaves et aux nœuds Sentinel restants pour vérifier s'ils sont en ligne. Si le serveur répond normalement à la commande PING, le nœud sentinelle considère le serveur comme en ligne. Si le serveur ne répond pas ou renvoie une erreur, le nœud sentinelle pense que le serveur est peut-être en panne ;
- Toutes les 2 secondes (par défaut), chaque nœud Sentinel enverra un message au
__sentinel__:hellocanal du nœud de données Redis. Ce message contient le jugement du nœud Sentinel sur le nœud maître et les informations du nœud Sentinel actuel ; - Toutes les 10 secondes (par défaut), chaque nœud Sentinel enverra périodiquement (par défaut toutes les 10 secondes) des commandes INFO au nœud maître et à tous les nœuds esclaves pour obtenir la dernière topologie et d'autres informations. La commande INFO peut renvoyer diverses informations et statistiques du serveur Redis, notamment des informations générales sur le serveur (telles que la version Redis, l'heure de démarrage, le système d'exploitation, etc.), des informations de connexion client, l'utilisation de la mémoire, l'état de persistance des données, maître-esclave. Informations copiées, etc.
2.2. Redis Sentinel Mode - Téléchargement subjectif et objectif
Dans le mode sentinelle Redis, « hors ligne subjectif » et « hors ligne objectif » sont deux concepts importants qui servent de base au nœud Sentinel pour déterminer si le serveur principal est en panne.
Subjectif Down : chaque nœud Sentinel enverra périodiquement (par défaut toutes les secondes) des commandes PING au nœud maître, aux nœuds esclaves et aux autres nœuds Sentinel pour la détection des battements de cœur. Si un nœud down-after-millisecondsne répond pas efficacement dans le délai défini par les paramètres, le nœud Sentinel déterminera la défaillance du nœud. Ce comportement est appelé hors ligne subjectif.
Le mode hors ligne subjectif est basé sur le jugement du propre point de vue du nœud Sentinel. Cela signifie simplement que le nœud Sentinel ne peut pas communiquer normalement avec le nœud détecté, ce qui peut être dû à des problèmes de réseau ou à une défaillance réelle du nœud détecté.
Objectif en panne : lorsqu'un nombre suffisant de nœuds Sentinel estiment que le serveur principal est hors ligne, le serveur principal est alors considéré comme étant objectivement hors ligne. Il s’agit du consensus de la plupart des nœuds Sentinel et il est plus crédible.
En mode sentinelle Redis, lorsqu'un nœud Sentinel détermine subjectivement que le nœud maître est hors ligne, il demandera sentinel is-master-down-by-addraux autres nœuds Sentinel leur jugement sur le nœud maître via des commandes. Si la réponse reçue indique que le nombre de nœuds Sentinel qui pensent que le nœud maître est hors ligne atteint quorumla valeur définie par le paramètre, alors le nœud Sentinel pensera qu'il y a effectivement un problème avec le nœud maître et prendra la décision objective de se déconnecter. .
En mode Sentinel, le processus de basculement sera déclenché uniquement lorsque le serveur principal est jugé objectivement hors ligne. Cela permet d'éviter les faux positifs dus à des problèmes de réseau ou à des erreurs d'appréciation des nœuds Sentinel individuels. Ce n'est que lorsque la plupart des nœuds Sentinel pensent que le serveur principal est hors ligne que cela est considéré comme une véritable panne et qu'un basculement est requis.
2.4. Élection du nœud en mode Redis Sentinel
En mode sentinelle Redis, lorsque le nœud maître est jugé objectivement hors ligne, le nœud sentinelle procédera à une élection de leader et sélectionnera un nœud Sentinel leader qui sera responsable du processus de basculement. Voici les étapes détaillées de l’élection du nœud Sentinel leader :
- Démarrer l'élection : lorsqu'un nœud Sentinel détermine que le nœud maître est objectivement hors ligne, il lance un nouveau processus d'élection de leader. Tout d'abord, il incrémente son époque de configuration (un nombre global incrémentiel), puis envoie un message demandant un vote aux autres nœuds Sentinel ;
- Vote : lorsqu'un nœud Sentinel reçoit un message demandant un vote, si l'époque de configuration dans la demande est supérieure à sa propre époque de configuration, il mettra à jour sa propre époque de configuration et enverra un message de vote au nœud Sentinel demandant le vote. Chaque nœud Sentinel ne peut voter qu'une seule fois au cours d'une époque de configuration ;
- Vote statistique : le nœud Sentinel qui demande un vote comptera les messages de vote reçus. S'il reçoit les votes de la majorité des nœuds Sentinel dans le délai spécifié (la valeur par défaut est de 2 secondes), il sera élu leader ;
- Démarrer le basculement : le nœud Sentinel leader démarrera le processus de basculement, y compris l'élection d'un nouveau nœud maître, la reconfiguration des nœuds esclaves, etc.
Grâce à ce processus, le système Sentinel peut rapidement élire un leader pour le basculement après la défaillance du nœud maître, garantissant ainsi la haute disponibilité du service Redis.
2.5. Basculement en mode Redis Sentinel
En mode sentinelle Redis, lorsque le nœud maître est jugé objectivement hors ligne, le nœud sentinelle basculera, élira un nouveau nœud maître et reconfigurera le nœud esclave. Voici les étapes détaillées du basculement :
- Élire un nouveau nœud maître : tout d’abord, le nœud Sentinel leader élira un nouveau nœud maître parmi tous les nœuds esclaves. Le principe de l'élection est de donner la priorité au nœud esclave possédant les données les plus récentes (le décalage de réplication le plus important) et la priorité la plus élevée.
- Envoyez la commande SLAVEOF NO ONE : Le nœud Sentinel leader enverra la commande au nœud maître nouvellement élu
SLAVEOF NO ONEpour en faire le nouveau nœud maître. SLAVEOFReconfigurez le nœud esclave : le nœud Sentinel leader enverra ensuite des commandes aux autres nœuds esclaves pour en faire des nœuds esclaves du nouveau nœud maître.- Mettre à jour les métadonnées : Enfin, tous les nœuds Sentinel mettront à jour leurs propres métadonnées, y compris l'adresse du nœud maître, la relation maître-esclave, etc.
- Notifier les clients : tous les nœuds Sentinel enverront
+switch-masterdes messages aux clients abonnés à l'événement, les informant que le nœud principal a été commuté.
Grâce à ce processus, le système Sentinel peut rapidement effectuer un basculement après une panne du nœud maître, garantissant ainsi la haute disponibilité du service Redis.
3. Implémentation de la réplication maître-esclave Redis
3.1. Extrayez l'image Redis
Extrayez l'image Redis :
docker pull redis
3.3. Créez les dossiers requis
Créez les dossiers requis pour mapper les chemins de fichiers correspondants du conteneur :
mkdir -p ~/data/redis/master/data
touch ~/data/redis/master/redis.confmkdir
touch ~/data/redis/master/redis.conf
mkdir -p ~/data/redis/slave-1/data
touch ~/data/redis/slave-1/redis.confmkdir
touch ~/data/redis/slave-1/redis.conf
mkdir -p ~/data/redis/slave-2/data
touch ~/data/redis/slave-2/redis.confmkdir
touch ~/data/redis/slave-2/redis.conf
mkdir -p ~/data/redis/slave-3/data
touch ~/data/redis/slave-3/redis.confmkdir
touch ~/data/redis/slave-3/redis.conf
# sentinel.conf 文件一个就够
touch ~/data/redis/master/sentinel.conf
3.3.Modifier redis.conf
Modifier le fichier redis.conf du nœud maître
bind 0.0.0.0
# 开启保护模式，限制为本地访问，默认yes
protected-mode no
# 默认no，改为yes意为以守护进程方式启动，可后台运行，除非kill进程，改为yes会使配置文件方式启动redis失败
daemonize no
# redis持久化（可选）
appendonly yes
Modifier le fichier redis.conf du nœud esclave
bind 0.0.0.0
# 开启保护模式，限制为本地访问，默认yes
protected-mode no
# 默认no，改为yes意为以守护进程方式启动，可后台运行，除非kill进程，改为yes会使配置文件方式启动redis失败
daemonize no
# redis持久化（可选）
appendonly yes
# 指向master节点
replicaof 172.17.0.2 6379
3.4. Modifier sentinel.conf
Modifier le fichier sentinel.conf
daemonize yes
sentinel monitor mymaster 172.17.0.2 6379 2
port 26379
4.5. Exécuter le conteneur
Exécutez le conteneur et spécifiez le chemin de montage :
docker run -p 16379:6379 -p 16389:26379 --name redis-master -v ~/data/redis/master/data/:/data -v ~/data/redis/master/sentinel.conf:/etc/redis/sentinel.conf -v ~/data/redis/master/redis.conf:/etc/redis/redis.conf -d redis redis-server /etc/redis/redis.conf --appendonly yes
---
docker run -p 26379:6379 -p 16390:26379 --name redis-slave-1 -v ~/data/redis/slave-1/data/:/data -v ~/data/redis/slave-1/sentinel.conf:/etc/redis/sentinel.conf -v ~/data/redis/slave-1/redis.conf:/etc/redis/redis.conf -d redis redis-server /etc/redis/redis.conf --appendonly yes
---
docker run -p 36379:6379 -p 16391:26379 --name redis-slave-2 -v ~/data/redis/slave-2/data/:/data -v ~/data/redis/slave-2/sentinel.conf:/etc/redis/sentinel.conf -v ~/data/redis/slave-2/redis.conf:/etc/redis/redis.conf -d redis redis-server /etc/redis/redis.conf --appendonly yes
---
docker run -p 46379:6379 -p 16392:26379 --name redis-slave-3 -v ~/data/redis/slave-3/data/:/data -v ~/data/redis/slave-3/sentinel.conf:/etc/redis/sentinel.conf -v ~/data/redis/slave-3/redis.conf:/etc/redis/redis.conf -d redis redis-server /etc/redis/redis.conf --appendonly yes
Afficher via Docker Desktop :
4.6. Afficher les informations sur le nœud maître-esclave
Afficher les informations sur le nœud maître-esclave :
# 进入从节点服务
docker exec -it [CONTAINER ID] redis-cli
# 查看角色信息
127.0.0.1:6379> role
# 查看主从复制信息
127.0.0.1:6379> info replication
Nœud maître :
Depuis le nœud :
