Résumé et partage de trois modes de cluster de Redis

Cet article vous apporte des connaissances pertinentes sur Redis dispose de trois modes de cluster, parmi lesquels maître-esclave est le mode le plus courant. Aujourd'hui, à travers cet article, je vais partager avec vous une introduction aux trois modes de cluster de Redis. Les amis intéressés peuvent nous rejoindre, j'espère que cela aidera tout le monde.

Apprentissage recommandé : Tutoriel vidéo Redis

Trois modes de cluster

• Redis dispose de trois modes de cluster, parmi lesquels maître-esclave est le mode le plus courant.
• Sentinel Le mode Sentinel a été évolué pour compenser la complexité du basculement maître-esclave après la panne de l'hôte du cluster de réplication maître-esclave. Comme son nom l'indique, Sentinel est utilisé pour la surveillance. Sa fonction principale est de surveiller le cluster maître-esclave, de basculer automatiquement entre maître et esclave et d'effectuer le basculement complet du cluster.
• Le mode cluster est le mode cluster officiellement fourni par redis. Il utilise la technologie Sharding pour non seulement obtenir une haute disponibilité, une séparation en lecture et en écriture, mais également obtenir un véritable stockage distribué.

1. Réplication maître-esclave

Réplication maître-esclave redis

1. Le mode maître-esclave reids

2. synchronisation des opérations (SYNC)) et propagation des commandes

La synchronisation (SYNC) est utilisée pour mettre à jour l'état du serveur esclave afin d'être cohérent avec le serveur maître. L'explication vernaculaire consiste à obtenir activement les données du serveur principal à partir du serveur. Gardez vos données cohérentes. L'implémentation spécifique est qu'après avoir reçu la commande SYNC, le serveur maître génère un fichier instantané RDB puis l'envoie au serveur esclave.

La propagation des commandes est utilisée pour propager des commandes afin de maintenir le serveur esclave cohérent avec l'état du serveur maître après que les données du serveur maître sont modifiées et que le maître esclave est incohérent. L'explication vernaculaire est qu'une fois que le serveur maître a reçu la commande de modification des données du client, les données de la base de données changent et la commande est mise en cache, puis la commande mise en cache est envoyée au serveur esclave pour obtenir la cohérence des données maître-esclave en chargeant. la commande mise en cache. C'est ce qu'on appelle la propagation des commandes.

• Pourquoi il existe deux types d'opérations de réplication, la synchronisation et la propagation des commandes : Lorsqu'il n'y a qu'une opération de synchronisation, lorsque le serveur esclave envoie la commande SYNC au serveur maître, le serveur maître recevra toujours la modification de commande du client lors de la génération du RDB fichier d'instantané. État des données, si cette partie des données ne peut pas être communiquée au serveur esclave, alors les données maître-esclave seront incohérentes. À ce stade, la propagation des commandes se produit. Une fois que le serveur maître a reçu la commande SYNC du serveur esclave, il génère un fichier instantané RDB et met en cache les commandes reçues pendant cette période, puis utilise l'opération de propagation des commandes pour les envoyer au serveur esclave. . Pour obtenir la cohérence des données maître-esclave.
• 3. Principe de réplication maître-esclave Redis

Les deux opérations de réplication Redis sont présentées ci-dessus, et la réplication maître-esclave Redis est officiellement implémentée sur la base de la synchronisation et de la propagation des commandes. Les deux images suivantes montrent le processus de réplication redis :

4 Avantages et inconvénients de la réplication maître-esclave redis

Avantages : 1. résoudre la panne d'une seule machine 2. Pendant la réplication maître-esclave, le maître et l'esclave ne sont pas bloquants et sont toujours disponibles.

Inconvénients :

1. Pendant le temps d'arrêt du maître, vous devez changer manuellement d'hôte. En même temps, certaines données ne peuvent pas être synchronisées avec le serveur esclave à temps, provoquant une incohérence des données (une intervention manuelle est requise)

2. .Une fois l'esclave en panne, plusieurs esclaves Après la récupération, un grand nombre de synchronisations SYNC doubleront la pression d'E/S du maître (le temps de démarrage peut être évité manuellement)

3.

Résumé :

Les avantages de la réplication maître-esclave Redis sont principalement une disponibilité améliorée. Inconvénients

2. Mode Sentinel

Sentinel Sentinel Introduction à Sentinel

Sentinel est essentiellement une instance Redis exécutée dans un mode spécial, juste l'initialisation. le processus et le travail sont différents de Redis ordinaire, et il s'agit essentiellement d'un processus distinct.

Sentinel est une solution haute disponibilité pour Redis : un système Sentinel (système) composé d'une ou plusieurs instances (instances) Sentinel peut surveiller n'importe quel nombre de serveurs maîtres, ainsi que tous les serveurs esclaves sous ces serveurs maîtres, et surveiller les serveur maître. Lorsque le serveur est hors ligne, il peut automatiquement passer du serveur esclave au serveur maître.

1. Système Sentinel

La figure suivante est un schéma simple de l'architecture du système Sentinel. Un système Sentinel surveille un cluster maître-esclave, où le serveur1 est le serveur maître Redis et le serveur2/3/4 sont les serveurs esclaves Redis. La réplication maître-esclave ci-dessus est utilisée entre maître et esclave pour assurer la cohérence maître-esclave. Le système Sentinel surveille l'ensemble du cluster maître-esclave.

2. Basculement Sentinel

Lorsque le système Sentinel détecte que le serveur principal du serveur 1 est hors ligne, il mettra fin à la réplication du serveur 2/3/4.

En même temps, Sentinel met à niveau le serveur2 vers le serveur principal et le serveur3/4 se réplique à partir du nouveau serveur principal. En même temps, attendez que le serveur 1 soit à nouveau en ligne.

Le système Sentinel peut également rétrograder activement le service principal vers un serveur esclave et mettre à niveau le serveur esclave vers le serveur maître.

2.1. Processus de surveillance Sentinel

Processus du cluster de surveillance Sentinel :

• Command Sentinel envoie une commande pour remettre le serveur Redis à l'état d'exécution. Publier et s'abonner Lorsque l'état du serveur maître change, Sentinel informe les autres serveurs esclaves via le
• mode de publication et d'abonnement.

2.2. Basculement de Sentinel

Basculement de Sentinel :

• 1. L'instance Sentinel dans le système Sentinel envoie une commande PING au cluster toutes les secondes
• 2. instance dans le cluster Si le temps d'arrêt de l'instance dépasse quelques millisecondes, alors l'instance Sentinel qui a envoyé la commande PING sera subjectivement hors ligne
• 3. Alors, quand sera-t-elle objectivement hors ligne ? Les autres instances du système Sentinel doivent confirmer que le superviseur d'instance du cluster est hors ligne.
• Si le serveur maître est marqué comme hors ligne subjectif, le processus Sentinel surveillant le maître dans le système Sentinel doit confirmer si le maître entre dans l'état hors ligne de superviseur une fois par seconde
• 4. Lorsqu'il y a suffisamment d'instances Sentinel (en fonction de la configuration). ) Confirmez que le Maître est entré dans la supervision hors ligne, le Maître sera alors marqué comme objectivement hors ligne.
  

3. Avantages et inconvénients de Sentinel

Avantages :

1. Le mode Sentinel est basé sur la réplication maître-esclave, donc Sentinel a les avantages de la réplication maître-esclave 2. Sentinel a le maître. -Commutation et échec d'esclave. Le cluster a donc une plus grande disponibilité

Inconvénients :

1. Redis est difficile à prendre en charge l'expansion en ligne, et l'expansion en ligne est plus compliquée.

Résumé :
sentinel est principalement utilisé pour surveiller le cluster maître-esclave Redis et améliorer la disponibilité du cluster maître-esclave Redis.

3. Mode cluster

redis cluster

1. reids cluster

Redis Cluster est une technologie de partage de serveur et la version redis 3.0 est officiellement disponible.
Sentinel a essentiellement atteint une haute disponibilité, mais chaque machine stocke le même contenu, ce qui gaspille de la mémoire, donc Redis Cluster implémente le stockage distribué. Un contenu différent est stocké sur chaque nœud de machine.

2. Principe de partage des données du cluster Redis

Le partage des données Redis utilise des emplacements de hachage. Le cluster Redis dispose de 16 384 emplacements de hachage. Chaque clé est modulo 16 384 après avoir réussi la vérification CRC16.
Lors de l'accès à la clé redis, redis obtiendra un résultat basé sur l'algorithme CRC16, puis calculera le reste du résultat et 16384, et utilisera cette valeur pour obtenir les données du nœud correspondant.
À l'heure actuelle, le client de l'application n'a en fait besoin que de se connecter à l'un des nœuds, puis chaque nœud du cluster Redis enregistre les informations d'emplacement des autres nœuds. De cette manière, une fois que la clé d'accès a calculé l'emplacement, les informations de nœud sont obtenues à partir de la configuration en enregistrant les informations d'emplacement, puis le nœud correspondant est récupéré pour obtenir les données.

3. Principe de réplication du cluster Redis

le cluster redis introduit le modèle de réplication maître-esclave. Un nœud maître correspond à un ou plusieurs nœuds esclaves. Lorsque le nœud maître tombe en panne, les nœuds esclaves seront activés. Lorsque d'autres nœuds maîtres envoient une requête ping à un nœud maître A, si plus de la moitié des nœuds maîtres communiquent avec A expirent, alors le nœud maître A est considéré comme étant en panne. Si le nœud maître A et son nœud esclave A1 sont en panne, alors le cluster ne peut plus fournir de services

Apprentissage recommandé :Tutoriel vidéo Redis

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!