❝Sentinel est principalement une solution pour les pannes d'un seul nœud qui ne peut pas être récupéré automatiquement. Le cluster est principalement une solution pour la capacité d'un nœud unique, les problèmes de concurrence et d'évolutivité linéaire. officiel Le cluster redis fourni. À la fin de l'article, vous pouvez configurer l'arrière-plan ssh que vous souhaitez >
❝
Le clustering consiste à résoudre le problème de Limite de mémoire sur une seule machine et concurrence dans la réplication maître-esclave. Si vous êtes maintenant La mémoire du service cloud est de 256 Go. Lorsque cette mémoire est atteinte, Redis ne sera plus en mesure de fournir des services en même temps, si le volume de données atteint. À ce stade, la quantité de données écrites sera très importante, ce qui peut facilement provoquer un débordement de tampon et empêcher la copie complète illimitée du nœud maître-esclave de fonctionner correctement.
Ensuite, nous devons changer le maître-esclave de la machine unique en plusieurs-à-plusieurs et tous maîtres nœuds Ils sont tous connectés entre eux et communiquent entre eux. Cette méthode permet non seulement de partager la mémoire d'une seule machine, mais également de répartir les requêtes et d'améliorer la disponibilité du système.
Comme le montre la figure : Lorsqu'il y a un grand nombre de requêtes à écrire, les instructions ne seront plus envoyées à un seul nœud maître, mais les instructions seront distribuées à différents nœuds maîtres pour partager la mémoire et éviter un grand nombre de demandes.
Alors, comment les instructions sont-elles dérivées et stockées ? Nous devons en savoir plus sur la structure de stockage du cluster.
Comment comprendre comment pour améliorer la disponibilité du système En termes de disponibilité, regardons l'image ci-dessous. Lorsque master1 tombe en panne, l'impact sur le système ne sera pas si important et les services normaux pourront toujours être fournis.
À ce moment-là, quelqu'un demandera : comment fonctionne le cluster lorsque master1 tombe en panne ? Cette question trouvera une réponse pour vous dans le basculement ci-dessous. Et cette problématique sera expliquée en détail dans le chapitre principal
En fait, redis a divisé l'espace de stockage en
parties après le démarrage du cluster, et chaque hôte en enregistre une partie.16384
Ce qu'il faut noter ici, c'est que le numéro que j'ai donné à chaque espace de stockage redis est équivalent à un petit espace de stockage (
专业术语“哈希槽”
Le 28 pointé par la flèche signifie que 28 sera stocké dans cette zone. Cette maison peut stocker 29, 30, 31, etc.
La question se pose à ce moment-là, que doit-on faire si l'on ajoute ou supprime une machine ? Regardez des images pour parler et essayez de ne pas utiliser de mots si vous pouvez utiliser des images pour expliquer.
Après l'ajout d'une nouvelle machine, certains emplacements seront alloués à la nouvelle machine parmi les trois autres espaces de stockage. Ici, vous pouvez définir le nombre d'emplacements que vous souhaitez installer dans la nouvelle machine.
De même, après avoir réduit une machine, les emplacements supprimés seront réaffectés à d'autres machines existantes. Tout comme l'ajout d'un nouveau nœud, vous pouvez spécifier l'emplacement de réception du nœud.
Ce qu'on appelle l'ajout d'un nœud ou la suppression d'un nœud consiste à modifier l'emplacement où l'emplacement est stocké. Après avoir compris la structure de stockage du cluster, nous devons expliquer une autre question, comment concevoir la communication interne du cluster ! Une valeur arrive, une clé est obtenue, où obtenir les données, et nous examinerons cette question ci-dessous.
Chaque nœud du cluster enverra des pings à d'autres nœuds dans une certaine période de message temporel, les autres nœuds renvoient pong en réponse. Après un certain temps, tous les nœuds connaîtront les informations d'emplacement de tous les nœuds du cluster.
S'il y a trois nœuds comme indiqué ci-dessous, alors les 16384 emplacements de hachage seront divisés en trois parties.
sont respectivement 0-5500, 5501-11000, 11001-16384
Lorsqu'un utilisateur lance une demande de clé, comment le cluster traite-t-il la demande ?
La boîte noire dans l'image ci-dessous représente les informations d'emplacement de tous les nœuds du cluster, et elle contient de nombreuses autres informations.
Comme le montre la figure, l'utilisateur lance une demande de clé, et redis calcule la position de l'emplacement de la clé après l'avoir reçue, et trouve le nœud correspondant en fonction de la position de l'emplacement
Si l'emplacement accédé se trouve sur le nœud lui-même, alors les données correspondant à la clé seront renvoyées directement.
Sinon, une erreur de redirection déplacée sera répondue et le nœud correct sera renvoyé au client.
Ensuite, renvoyez le raccourci clavier
Faites simplement attention aux informations de configuration dans le cercle de clic
Kaka. donne Nous fournissons une commande qui peut facilement remplacer le fichier sed 's/6379/6380/g' 6379-redis.conf > 6380-redis.conf
Créez des fichiers de configuration pour 6 ports différents de cette manière
Ouvrez simplement un fichier de configuration pour vérifier et vérifier si le remplacement réussi Afin de faciliter la visualisation des informations du journal, toutes sont démarrées au premier plan. Et vérifiez si les services démarrent normalement. Exécutez la commande ps -ef | grep redis
Vous pouvez voir qu'il y a un logo de cluster supplémentaire après le démarrage, ce qui signifie qu'il s'agit de tous des nœuds du cluster. Tous les nœuds ont été démarrés. Les instructions de démarrage du cluster doivent être basées sur Ruby (Kaka utilise Redis version 4.0). Ensuite, installez-le ensemble
Exécutez la commande wget https://cache.ruby-lang.org/pub/ruby/2.7/ruby-2.7.1.tar.gz
Décompressez : tar -xvzf ruby-2.7.1.tar.gz
Téléchargez selon à votre propre version requise pour décompresser l'
installation : ./configure | make | make install
Ces trois instructions sont en une seule fois.
Voir les versions rubis et gemme : ruby -v
La commande d'exécution du cluster est dans /usr/local/redis/src/redis-trib.rb
Notez que si vous devez utiliser la commande redis-trib.rb
directement, vous devez vous rendre dans le répertoire bin, sinon vous devez utilisez la méthode ./redis-trib.rb
.
Si vous suivez les étapes, une erreur apparaîtra iciExécutergem install redis
Malheureusement, une erreur apparaîtra ici également. Vous devrez ensuite installer yum install zlib-devel
et yum install openssl-devel
Une fois l'installation terminée, exécutez /ruby-2.7.1/ext/openssl
sur /ruby-2.7.1/ext/zlib
et ruby extconf.rb
respectivement et exécutez make | make install
puis exécutez gem install redis
et tout ira bienÀ ce moment , revenez en arrière et exécutez ./redis-trib.rb create --replicas 1 127.0.0.1:6379 127.0.0.1:6380 127.0.0.1:6381 127.0.0.1:6382 127.0.0.1:6383 127.0.0.1:6384
「Interprétation des informations」
Créez un cluster et attribuez des emplacements de hachage à 6 nœuds. Les trois derniers nœuds sont configurés comme nœuds esclaves du premier. trois nœudsAfficher les informations sur l'emplacement de hachage et l'ID de chaque nœud Dans la dernière étape, vous devez entrer yes
pour afficher les modifications apportées au fichier de configuration dans le répertoire de données. L'information principale du fichier de configuration est l'emplacement attribué à chaque nœud maître "Afficher le journal d'exécution du point hôte"
Les principales informations données ici sont l'état du cluster modifié :ok L'état du cluster est normal
Lors de la définition directe des données, une erreur sera signalée, et la position de l'emplacement après la conversion de la clé de nom est 5798 et l'adresse IP et le numéro de port sont donnés. Vous devez utiliser la commande redis-cli -c
lors de la définition de la valeur, elle vous demandera de rediriger vers l'emplacement de 5798 Ensuite, vous obtiendrez les données et le nœud sera commuté automatiquement.
D'après les informations de démarrage du cluster ci-dessus, nous savons que le port 6383 est le nœud esclave du 6379.
L'étape suivante consiste à laisser le 6383 se déconnecter pour afficher les informations du journal du 6379.
6379 signalera que la connexion 6383 est perdue et la marquera comme échec, indiquant qu'elle n'est pas disponible. À l’heure actuelle, le cluster fonctionne toujours normalement.
"Résumé : les nœuds esclaves hors ligne n'ont aucun impact sur le cluster"Lorsque le port 6383 est mis en ligne, tous les nœuds effaceront la marque d'échec
Déconnectez manuellement le nœud maître 6379, vérifiez les informations de journal du nœud esclave 6383
À ce moment, le nœud 6383 continuera à se connecter au 6379 pour un total de 10 fois. Alors pourquoi 10 fois !
Il est déterminé en fonction des paramètres que nous avons configurés cluster-node-timeout 10
Les informations données ici sont de se connecter une fois par seconde
jusqu'à l'expiration du délai, puis de démarrer le basculement.
À ce moment-là, 6383 a réussi l'élection de basculement, et l'esclave s'est retourné et est devenu le nœud maître. À ce stade, vérifiez les informations sur le nœud du cluster et utilisez la commande cluster nodes
.
Vous constaterez qu'il y a quatre nœuds maîtres ici, mais l'un des nœuds maîtres est hors ligne "Le nœud maître d'origine 6379 est mis en ligne"
Après 6379 est en ligne, tous les nœuds effaceront également les informations d'échec.
Et les informations sur le nœud changeront également. À ce moment, 6379 passe au nœud esclave de 6383.
Ajouter deux nouveaux ports 6385 et 6386 Exécutez la nouvelle commande./redis-trib.rb add-node 127.0.0.1:6385 127.0.0.1:6379
, ce qui est envoyé ici est le message de rencontre
Exécutez la commande add-node, le premier paramètre est l'ip+port du nouveau nœud, et le deuxième paramètre est le nœud qui existe déjà dans le cluster. D'après la figure ci-dessous, nous pouvons voir que les nœuds nouvellement ajoutés existent déjà dans le cluster.
"Remarque : bien que 6385 soit devenu un nœud dans le cluster, il est différent des autres nœuds. Il n'a pas de données, c'est-à-dire pas d'emplacement de hachage" Ensuite, nous allons Certains emplacements de hachage du cluster doivent être alloués à ce nouveau nœud. Une fois l'allocation terminée, ce nœud deviendra le véritable nœud maître
Exécutez la commande./redis-trib.rb reshard 127.0.0.1:6385
et vous le ferez. être demandé Combien d'emplacements de hachage transférer et remplir le id
du nœud de réception La dernière étape demande s'il faut transférer depuis tous les nœuds : Kaka utilise all
Utilisez la commande : cluster nodes
Vérifiez que le nœud 6385 dispose déjà de trois plages d'emplacements de hachage
"Le nœud maître a été ajouté et l'étape suivante est Vous devez configurer un nœud esclave 6386 pour le nœud maître 6385"
Commande : ./redis-trib.rb add-node --slave --master-id dcc0ec4d0c932ac5c35ae76af4f9c5d27a422d9f 127.0.0.1:6386 127.0.0.1:6385
master-id est l'identifiant de 6385, et le premier paramètre est l'ip+port du nouveau nœud Le second est le nœud maître désigné ip + port
Quand. vous souhaitez Si vous mettez à niveau le nœud maître dans le cluster, vous pouvez effectuer manuellement un basculement vers le nœud esclave pour éviter d'affecter la disponibilité du cluster.
Exécutez la commande sur le nœud esclave : cluster failover
"Processus d'exécution"
Affichez les informations sur le nœud et vous pouvez voir que le nœud 6386 est devenu le point hôte.
Lorsque la commande de basculement du cluster est envoyée au nœud esclave, le nœud esclave enverra le paquet CLUSTERMSG_TYPE_MFSTART au nœud maître. Le nœud esclave demande au nœud maître d'arrêter d'accéder, afin que les décalages de données des deux soient cohérents.
À ce moment-là, le client ne se connectera pas au nœud maître éliminé. En même temps, le nœud maître envoie le décalage de réplication au nœud esclave. Une fois que le nœud esclave a obtenu le décalage de réplication, le basculement démarre, puis. informe le nœud maître d'effectuer un changement de configuration. Lorsque le client Le client est déverrouillé sur l'ancien maître et se reconnecte au nouveau nœud maître.
Dans ce qui précède, nous avons testé le basculement, sous le nœud maître après le ligne, le nœud esclave devient le nœud maître. Ensuite, analysez ce processus.
Chaque nœud du cluster enverra périodiquement un message ping aux autres nœuds, le récepteur répond avec pong.
Si le message ping continue d'échouer dans le délai d'expiration du nœud de cluster, le nœud de réception sera marqué comme étant en état pfail, c'est-à-dire subjectivement hors ligne.
Ce statut hors ligne est-il très familier ? Oui, cela ressemble quelque peu au jugement de la sentinelle quant à savoir si le nœud maître est anormal. Lorsqu'une sentinelle détecte un problème avec le nœud maître, elle marquera également le nœud maître comme objectivement hors ligne (s_down). J'ai soudain réalisé que j'étais hors sujet, embarrassant...
Laissez-moi mentionner les sentinelles Lorsqu'une sentinelle pense que le nœud maître est anormal, elle le marque comme un hors-ligne subjectif. d'autres sentinelles sont d'accord ? Vous ne pouvez pas. Ce qui est dit est ce qui est dit. Ils essaieront tous de se connecter au nœud maître anormal. Lorsque plus de la moitié des sentinelles pensent que le nœud maître est anormal, elles mettront directement le nœud maître hors ligne de manière objective.
De même, le cluster ne jugera pas seulement que son état est hors ligne à cause d'un nœud. Le nœud se propage directement via des messages de potins. Les nœuds du cluster collecteront en permanence les commentaires hors ligne du nœud défectueux et les stockeront. sous le nœud local défectueux. Rapports en ligne. Lorsque plus de la moitié des nœuds maîtres du cluster sont marqués comme subjectivement hors ligne, l'état passe à objectivement hors ligne.
Enfin, un message d'échec est diffusé au cluster, informant tous les nœuds de marquer le nœud défaillant comme objectivement hors ligne.
Par exemple : le nœud A envoie un ping au nœud B, puis marque le nœud B comme pfail après une anomalie de communication. Ensuite, le nœud A continuera à envoyer des pings au nœud C et à transmettre les informations pfail du nœud B. Puis le nœud C. enregistrera la faute du nœud B hors ligne. Lorsque le nombre de rapports hors ligne est supérieur à la moitié du nombre de nœuds maîtres dotés d'emplacements de hachage, il tentera de se déconnecter objectivement.
Lorsque le nœud défaillant est défini comme objectif Après la mise hors ligne, tous les nœuds esclaves du nœud défectueux assument la responsabilité de la récupération des pannes.
La récupération sur panne est un processus de récupération sur panne qui sera exécuté une fois que le nœud esclave aura découvert que son point hôte est objectivement hors ligne via des tâches planifiées.
「1. Vérification de qualification」
Tous les nœuds esclaves vérifieront l'heure de la dernière connexion avec le nœud maître, et le temps de déconnexion est supérieur au temps du nœud du cluster *cluster -slave-validity-factor n'est pas éligible au basculement.
「2. Temps de préparation des élections」
Parlons d'abord de la raison pour laquelle il y a un temps de préparation des élections ici.
S'il y a plusieurs nœuds esclaves après le contrôle de qualification, différents délais d'élection doivent être utilisés pour prendre en charge la priorité. La priorité ici est En fonction du décalage de réplication, plus le décalage est grand, plus le délai entre le nœud maître défaillant est petit et plus les chances de remplacer le nœud maître sont grandes.
La fonction principale est de garantir que le nœud avec la meilleure cohérence des données lance l'élection en premier
「3. Vote électoral」
Mécanisme de vote. des nœuds esclaves du cluster Redis ne sont pas utilisés pour l'élection du leader. N'oubliez pas de ne pas confondre cela avec la sentinelle. Le mécanisme de vote du cluster est basé sur les points hôtes détenant les slots.
Le nœud esclave du nœud défaillant diffusera un paquet FAILOVER_AUTH_REQUEST à tous les nœuds maîtres détenant des emplacements pour demander des votes.
Lorsque le nœud maître répond à FAILOVER_AUTH_ACK pour voter, il ne peut pas voter pour d'autres nœuds esclaves pendant la période NODE_TIMEOUT * 2
Une fois que le nœud esclave a obtenu plus de la moitié des votes, il passera à la phase de récupération après échec
「4 Basculement」
L'esclave élu avec succès. Le nœud annule le changement de réplication Le nœud maître
supprime le slot du nœud défaillant et se confie le slot du nœud défaillant
diffuse son propre message pong au cluster, avertissant l'hôte de le changement et la reprise des informations d'emplacement du nœud défaillant.
Un article Redis Sentinel qui a pris deux nuits pour être terminé, mais vous ne vous concentrez pas sur l'article lui-même, ah ! Le cœur de l'éditeur fait mal
Afin de répondre à la demande de chacun, Kaka explique à contrecœur comment mettre en place un fond lumineux. L'outil utilisé par Kaka est xsheelOuvrez l'option de sélection d'outil Ensuite, allez voir s'il y a une fenêtre transparente, et vous pouvez définir la transparence de xsheel. Oui ! Vous avez raison. C'est l'arrière-plan du bureau. Êtes-vous prêt à commencer à le configurer ? Que diriez-vous de revenir après l'avoir configuré et lu l'article ? Kaka a également besoin d'experts de tous horizons pour apporter des points techniques et corriger les erreurs.
❝La persévérance dans l'apprentissage, la persévérance dans les blogs et la persévérance dans le partage sont les convictions auxquelles Kaka adhère depuis sa carrière. J'espère que les articles de Kaka dans l'immense Internet. peut vous apporter un peu Rendez-vous dans le prochain numéro
❞
Recommandé : "tutoriel 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!