Explication détaillée du mécanisme de haute disponibilité et de haute concurrence de Redis

1. Mécanisme à haute concurrence

Nous savons que Redis est basé sur un seul thread et peut être hébergé dans Stand. -mode seul Il ne s'agit que d'environ des dizaines de milliers, alors comment améliorer ses requêtes simultanées élevées de centaines de milliers sous le Big Data grâce à l'architecture maître-esclave de Redis et à la séparation de la lecture et de l'écriture.

Recommandation de cours vidéo → : "Solution de simultanéité de données à dix millions de niveaux (théorie + pratique)"

1 .Réplication maître-esclave

La configuration de la réplication maître-esclave redis n'est pas soulignée. Elle dépend principalement du principe et du processus de réplication maître-esclave : Dans le processus de réplication maître-esclave de redis, un maître. L'hôte est requis en tant qu'administrateur pour créer plusieurs machines esclaves. Lorsque l'esclave esclave essaie de démarrer, il enverra une commande PSYNC à l'hôte maître. Si l'esclave esclave est reconnecté à ce moment, les données dont l'esclave ne dispose pas seront copiées de l'hôte maître. première fois que vous vous connectez, une resynchronisation complète sera déclenchée. Après le déclenchement, l'hôte maître démarrera un processus en arrière-plan pour générer un fichier d'instantané RDB et stockera en même temps les opérations d'écriture au cours de cette période dans le cache. Lorsque le fichier RDB est généré, le fichier RDB sera envoyé. à la machine esclave, et la machine esclave obtiendra le fichier. Après cela, il est d'abord écrit sur le disque puis chargé dans la mémoire. Enfin, l'hôte maître enverra également les données mises en cache dans la mémoire à la machine esclave. en même temps. Si une panne de réseau maître-esclave se produit et que plusieurs esclaves se reconnectent, le maître ne redémarrera qu'un seul RDB pour servir tous les esclaves. [Recommandations associées : Tutoriel vidéo Redis]

Reprise du point d'arrêt : il y a un décalage de réplique dans le maître et l'esclave, et un identifiant de maître dedans. Le décalage est conservé dans le backlog et devient. le maître. Lorsque l'esclave se reconnecte après une panne de réseau, il trouvera le décalage de la dernière réplique correspondante et le copiera. Si le décalage correspondant n'est pas trouvé, une resynchronisation complète sera déclenchée.

①Processus de copie complet

(1) Le nœud esclave démarre et enregistre uniquement les informations du nœud maître, y compris l'hôte et l'adresse IP du nœud maître, mais le processus de copie ne démarre pas

D'où viennent l'hôte maître et l'IP ? La configuration esclave dans redis.conf est

(2) Il y a une tâche planifiée à l'intérieur du nœud esclave pour vérifier s'il y a un nouveau nœud maître à connecter et copiez chaque seconde. Si vous trouvez cela, établissez une connexion réseau socket avec le nœud maître
(3) Le nœud esclave envoie une commande ping au nœud maître
(4) Authentification par mot de passe Si le maître définit requirepass, alors le nœud esclave doit envoyer le mot de passe masterauth pour l'authentification.
(5) Le nœud maître effectue une réplication complète pour la première fois et envoie toutes les données au nœud esclave
(6) Le nœud maître continue de copier l'écriture de manière asynchrone. commandes vers le nœud esclave

②Synchronisation des données Le mécanisme de base pertinent

fait référence à la copie complète effectuée lorsque l'esclave se connecte à msater pour la première fois, et à certains de vos mécanismes détaillés dans ce processus

(1) Le maître et l'esclave le maintiendront. Un décalage

Le maître accumulera continuellement des décalages sur lui-même, et l'esclave accumulera également continuellement des décalages sur lui-même
L'esclave fera rapport. son propre décalage vers le maître chaque seconde, et le maître enregistrera également le décalage de chaque esclave

Cela ne signifie pas qu'il est spécifiquement utilisé pour une réplication complète. La raison principale est que le maître et l'esclave doivent le faire. connaître le décalage de leurs propres données afin de connaître l'incohérence des données entre elles

(2) backlog

Le nœud maître a un backlog, la taille par défaut est de 1 Mo
Quand le nœud maître copie les données sur le nœud esclave, il écrira également une copie des données de manière synchrone dans le backlog
Le backlog est principalement utilisé pour la réplication complète

pour une copie incrémentielle lors d'une interruption (3) exécution du maître id

serveur d'informations, vous pouvez voir l'identifiant d'exécution du maître
Si vous localisez le nœud maître en fonction de l'hôte + ip, il n'est pas fiable Oui, si le nœud maître redémarre ou si les données changent, le nœud esclave devrait être distingué en fonction des différents identifiants d'exécution. Si l'identifiant d'exécution est différent, une copie complète doit être effectuée
Si vous devez redémarrer Redis sans modifier l'identifiant d'exécution, vous pouvez utiliser la commande redis-cli debug reload

(4) psync

Le nœud esclave utilise psync pour copier à partir du nœud maître, psync runid offset
Le nœud maître renverra les informations de réponse en fonction de sa propre situation, il se peut que le décalage runid FULLRESYNC se déclenche le montant total Copier, il se peut que CONTINUE déclenche une copie incrémentielle

③Copie complète

(1) Le maître exécute bgsave et génère un fichier instantané rdb localement
(2) Le nœud maître envoie le fichier instantané rdb au nœud esclave si le temps de copie rdb dépasse 60 secondes (repl-timeout), alors l'esclave Le nœud pensera que la copie a échoué, et vous pouvez ajuster ce paramètre de manière appropriée
(3) Pour les machines équipées de cartes réseau Gigabit, 100 Mo, 6 Go de fichiers sont généralement transférés par seconde, ce qui est susceptible de dépasser 60 s
(4) Le nœud maître génère rdb, toutes les nouvelles commandes d'écriture seront mises en cache en mémoire. Une fois que le nœud salve aura enregistré le rdb, les nouvelles commandes d'écriture seront copiées sur le nœud salve
(5) client-output-. buffer-limit slave 256MB 64MB 60, Si pendant la copie, la mémoire tampon continue de consommer plus de 64 Mo, ou dépasse 256 Mo à la fois, alors arrêtez la copie et la copie échoue
(6) Une fois que le nœud esclave a reçu le rdb, il efface ses propres anciennes données, puis recharge la rdb sur elle-même dans la mémoire, tout en fournissant des services externes basés sur l'ancienne version des données
(7) Si le nœud esclave active AOF, alors BGREWRITEAOF sera exécuté immédiatement, réécriture AOF

génération rdb, copie rdb via le réseau, esclave Le nettoyage des anciennes données et l'esclave aof réécriture prennent beaucoup de temps

Si la quantité de données copiées est comprise entre 4G et 6G, alors le le temps de copie complète est susceptible de prendre 1 minute et demie à 2 minutes

④Réplication incrémentielle

(1) Si la connexion réseau maître-esclave est déconnectée pendant le processus de réplication complète, alors lorsque l'esclave se reconnecte au maître, la réplication incrémentielle sera déclenchée
(2) Le maître copie directement à partir du sien Récupérez certaines données perdues du backlog et envoyez-les au nœud esclave. Le backlog par défaut est de 1 Mo
(3) msater. récupère les données du backlog en fonction du décalage dans psync envoyé par l'esclave

⑤heartbeat

Les nœuds maître et esclave s'enverront des informations de battement de cœur

Le maître envoie un battement de coeur toutes les 10 secondes par défaut, et le nœud salve envoie un battement de coeur toutes les 1 seconde

⑥Réplication asynchrone

Chaque fois que le maître reçoit une commande d'écriture, il écrit désormais les données en interne puis les envoie de manière asynchrone au nœud esclave

2. Séparation en lecture et en écriture : le maître est responsable de l'opération d'écriture et l'esclave est chargé d'aider le maître à atténuer les requêtes d'accès au volume

. 2. Mécanisme de haute disponibilité

Dans le cas d'une concurrence élevée, plusieurs clusters sont équipés d'un maître et de plusieurs sauvegardes. Bien que le problème de concurrence élevée puisse être résolu, il n'y a qu'un seul hôte. , si le maître est en panne, l'ensemble du système ne peut pas effectuer d'opérations d'écriture et l'esclave ne peut pas synchroniser les données, l'ensemble du système sera paralysé et l'ensemble du système sera indisponible. Le mécanisme de haute disponibilité de Redis est le mécanisme sentinelle. La sentinelle est un composant important du cluster Redis. Elle est responsable de la surveillance du cluster, de la notification des informations, du basculement et du centre de configuration.

(1) Surveillance du cluster, chargée de surveiller si les processus redis maître et esclave fonctionnent normalement
(2) Notification de message, si une instance redis échoue, la sentinelle est responsable de l'envoi de messages sous forme de notifications d'alarme à l'administrateur
(3) Failover, si le nœud maître raccroche, il sera automatiquement transféré au nœud esclave
(4) Centre de configuration, en cas de basculement, informer le client de la nouvelle adresse maître
Sentinel Il est distribué en lui-même et fonctionne comme un cluster et doit travailler ensemble.

Lorsque le nœud maître s'avère en panne, il nécessitera le consentement d'une majorité de sentinelles. Cela implique des élections distribuées.

Le mécanisme sentinelle doit assurer au moins 3 nœuds pour assurer sa robustesse. Si on ne donne que deux nœuds lors du test, l'un est le nœud maître et l'autre est le nœud esclave, alors il y a une sentinelle responsable. pour les deux nœuds. Surveillance, lorsque l'hôte maître tombe en panne, alors des sentinelles sont nécessaires pour l'élection, puis la sentinelle s1 dans le nœud maître ne peut plus fonctionner et l'élection ne peut être effectuée que par la sentinelle s2 dans le nœud esclave, alors une faute doit être effectuée après l'élection. Le transfert nécessite une sentinelle pour fonctionner, et son paramètre majoritaire précise le nombre de sentinelles nécessaires au basculement. A ce moment, il n'y a qu'une seule sentinelle S2 sans majorité pour le basculement. Il faut donc au moins 3 nœuds pour assurer sa robustesse.

3. Problèmes de perte de données résultant de la haute disponibilité et de la haute concurrence

(1) Perte de données causée par la réplication asynchrone

Parce que master -> La réplication de l'esclave est asynchrone, donc certaines données peuvent ne pas être copiées sur l'esclave avant la panne du maître, et ces parties des données sont perdues.

(2) Perte de données causée par split brain

Split brain, c'est-à-dire que la machine où se trouve un maître quitte soudainement le réseau normal et ne peut pas se connecter aux autres machines esclaves, mais en fait, le maître est toujours en lice.

À ce moment-là, la sentinelle peut penser que le maître est en panne, puis lancer l'élection et faire passer d'autres esclaves au maître

À ce moment-là. , il y aura deux esclaves dans le cluster. Il y a un maître, qui est ce qu'on appelle le cerveau divisé

Bien qu'un esclave soit basculé vers le maître à ce moment-là, le client n'aura peut-être pas le temps de changer. au nouveau maître, et les données qui continuent d'être écrites sur l'ancien maître ne peuvent pas être perdues,

Par conséquent, lorsque l'ancien maître sera à nouveau restauré, il sera accroché au nouveau maître en tant qu'esclave, ses propres données seront effacées et les données seront à nouveau copiées du nouveau maître.

Résoudre la perte de données causée par la réplication asynchrone et le split-brain

min-slaves-to-write 1
 min-slaves-max-lag 10

Nécessite au moins 1 esclave, le délai de réplication et de synchronisation des données ne peut pas dépasser 10 secondes

Si tous les esclave, les délais de réplication des données et de synchronisation dépassent 10 secondes, alors à ce moment, le maître ne recevra plus aucune requête

Les deux configurations ci-dessus peuvent réduire la perte de données causée par la réplication asynchrone et le split-brain

(1) Réduire la perte de données causée par la réplication asynchrone

Avec le min-slaves-max-lag configuration, on peut garantir qu'une fois que les données de copie de l'esclave et le délai ACK sont trop longs, on considère que trop de données peuvent être perdues après la panne du maître, puis la demande d'écriture est rejetée. Cela peut empêcher certaines données d'être perdues. synchronisé lorsque le maître tombe en panne. La perte de données causée par l'esclave est réduite dans la plage contrôlable

(2) Réduisez la perte de données causée par le split-brain

Si un maître a une scission. -brain et perd la connexion avec d'autres esclaves, alors les deux ci-dessus. Cette configuration peut garantir que s'il ne peut pas continuer à envoyer des données au nombre spécifié d'esclaves et que l'esclave ne s'envoie pas de message d'accusé de réception pendant plus de 10 secondes, alors le la demande d'écriture du client sera directement rejetée

De cette façon, l'ancien maître après le split brain n'acceptera pas de nouvelles données du client, évitant ainsi la perte de données

La configuration ci-dessus garantit que si la connexion est perdue avec un esclave et qu'aucun esclave ne se donne d'accusé de réception après 10 secondes, alors elle sera rejetée. Nouvelle demande d'écriture

Par conséquent, dans un scénario de split-brain, jusqu'à 10 secondes de données seront rejetées. soyez perdu

Pour plus de connaissances liées à la programmation, veuillez visiter : Introduction à la programmation ! !

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!