Une synchronisation / réplication maître-esclave
Grâce à la fonction de persistance, Redis garantit que les données ne seront pas perdues (ou une petite quantité de perte) même lorsque le serveur est redémarré, car la persistance enregistrera les données en mémoire sur le disque dur, et le redémarrage chargera les données à partir du disque dur. Mais comme les données sont stockées sur un serveur, si ce serveur rencontre des problèmes tels qu'une panne de disque dur, cela entraînera également une perte de données.
Afin d'éviter un point de défaillance unique, la pratique habituelle consiste à répliquer plusieurs copies de la base de données à déployer sur différents serveurs, de sorte que même en cas de défaillance d'un serveur, d'autres serveurs puissent continuer à fournir des services. À cette fin, Redis fournit une fonction de réplication, qui peut synchroniser automatiquement les données mises à jour avec d'autres bases de données lorsque les données d'une base de données sont mises à jour.
Dans le concept de réplication, les bases de données sont divisées en deux catégories, l'une est la base de données maître (maître) et l'autre est la base de données esclave (esclave). La base de données maître peut effectuer des opérations de lecture et d'écriture, et lorsque l'opération d'écriture entraîne des modifications de données, elle synchronise automatiquement les données avec la base de données esclave. La base de données esclave est généralement en lecture seule et accepte les données synchronisées à partir de la base de données maître. Une base de données maître peut avoir plusieurs bases de données esclaves et une base de données esclave ne peut avoir qu'une seule base de données maître.
Caractéristiques de réplication maître-esclave
* La base de données maître peut effectuer des opérations de lecture et d'écriture. Lorsque les données changent en raison d'opérations de lecture et d'écriture, les données seront automatiquement synchronisées avec la base de données esclave . Les bases de données esclaves sont généralement en lecture seule et reçoivent des données synchronisées à partir de la base de données maître. * Un maître peut avoir plusieurs esclaves, mais un esclave ne peut correspondre qu'à un seul maître * L'esclave se bloque n'affecte pas la lecture et l'écriture des autres esclaves et la lecture et l'écriture du maître. Après le redémarrage, les données seront synchronisées à partir du maître. * Après le maître se bloque, cela n'affectera pas la lecture de l'esclave, mais Redis ne fournit plus de services d'écriture. Après le redémarrage du maître, redis fournira à nouveau des services d'écriture externes . Une fois que le maître aura raccroché, il ne sélectionnera plus un maître dans le nœud esclave.
avantage:
Prend en charge la réplication maître-esclave, le maître synchronisera automatiquement les données avec l'esclave, qui peut séparer la lecture et l'écriture;
afin de décharger la pression d'opération de lecture du maître, le serveur esclave peut fournir au client des services d'opération en lecture seule, et le service d'écriture doit toujours être fourni par le maître complet; l'
esclave peut également accepter les connexions et les demandes de synchronisation d'autres esclaves, ce qui peut effectivement décharger la pression de synchronisation du
maître ; le serveur maître fournit des services pour les esclaves de manière non bloquante. Par conséquent, pendant la période de synchronisation maître-esclave, le client peut toujours soumettre des requêtes ou des demandes de modification; le
serveur esclave effectue également la synchronisation des données de manière non bloquante. Pendant la synchronisation, si un client soumet une demande de requête, Redis renverra les données avant la synchronisation;
Désavantages:
Redis ne dispose pas de fonctions de tolérance aux pannes et de récupération automatiques. Le temps d'arrêt de l'hôte et de l'esclave entraînera l'échec de certaines des demandes de lecture et d'écriture frontales. Vous devez attendre que la machine redémarre ou changer manuellement l'adresse IP frontale. à récupérer; l'
hôte est en panne, et certaines données ne sont pas opportunes avant le temps d'arrêt Synchronisez avec l'esclave, et le problème d'incohérence des données sera introduit après le commutateur IP, ce qui réduit la disponibilité du système;
si plusieurs esclaves sont déconnectés et doivent être redémarrés, essayez de ne pas redémarrer à la même période. Parce que tant que l'esclave est démarré, il enverra une demande de synchronisation et l'hôte sera entièrement synchronisé. Lorsque plusieurs esclaves sont redémarrés, cela peut entraîner une forte augmentation de l'E / S maître et provoquer des temps d'arrêt.
Redis est plus difficile à prendre en charge l'expansion en ligne, et l'expansion en ligne deviendra très compliquée lorsque la capacité du cluster atteindra la limite supérieure;
Deuxièmement, le mode sentinelle
Dans le premier mode de synchronisation / réplication maître-esclave, lorsque le serveur maître tombe en panne, un serveur esclave doit être basculé manuellement sur le serveur maître. Cela nécessite une intervention manuelle, laborieuse et laborieuse, et entraînera l'indisponibilité du service pendant un certain temps. période de temps. Ce n'est pas une méthode recommandée, le plus souvent, nous donnons la priorité au mode sentinelle.
Le mode sentinelle est un mode spécial. Tout d'abord, Redis fournit la commande de la sentinelle. La sentinelle est un processus indépendant. En tant que processus, il fonctionnera indépendamment. Le principe est que la sentinelle peut surveiller plusieurs instances Redis en cours d'exécution en envoyant des commandes et en attendant la réponse du serveur Redis.
Le rôle du mode sentinelle:
Envoyez une commande pour laisser le serveur Redis revenir pour surveiller son état de fonctionnement, y compris le serveur maître et le serveur esclave;
lorsque la sentinelle détecte que le maître est en panne, elle basculera automatiquement l'esclave vers le maître, puis notifiera les autres serveurs esclaves via le mode de publication et d'abonnement, et modifiez le fichier de configuration, laissez-les changer d'hôte;
cependant, un processus sentinelle pour surveiller le serveur Redis peut également avoir des problèmes. Pour cette raison, nous pouvons utiliser plusieurs sentinelles pour surveiller. Une surveillance sera également effectuée entre chaque sentinelle, formant ainsi un mode multi-sentinelle.
Le processus de basculement:
En supposant que le serveur principal est en panne, Sentinel 1 détecte d'abord ce résultat et le système n'effectuera pas immédiatement le processus de basculement. C'est juste que Sentinel 1 pense subjectivement que le serveur principal est indisponible et que ce phénomène devient subjectif hors ligne. Lorsque les sentinelles suivantes détectent également que le serveur principal est indisponible et que le nombre atteint une certaine valeur, un vote aura lieu parmi les sentinelles et le résultat du vote sera initié par une sentinelle pour effectuer une opération de basculement. Une fois le basculement réussi, chaque sentinelle utilisera le mode publication-abonnement pour basculer l'hôte du serveur esclave qu'il surveille. Ce processus est appelé objectif hors ligne. De cette façon, tout est transparent pour le client.
Comment fonctionne le mode sentinelle:
Chaque processus Sentinel envoie une commande PING au serveur maître maître, au serveur esclave et aux autres processus Sentinel de l'ensemble du cluster à une fréquence d'une fois par seconde.
Si une instance est supérieure à la valeur spécifiée par l'option down-after-millisecondes de la dernière réponse valide à la commande PING, l'instance sera marquée comme subjective down (SDOWN) par le processus Sentinel
si un serveur maître est marqué comme subjectif hors ligne (SDOWN), tous les processus Sentinel qui surveillent ce serveur maître maître doivent confirmer à une fréquence d'une fois par seconde que le serveur maître maître est bien entré dans l'état hors ligne subjectif.
Lorsqu'il y a suffisamment de Sentinel (sentinelle)) Le processus (supérieur ou égal à la valeur spécifiée dans le fichier de configuration) confirme que le serveur maître maître est entré dans l'état hors ligne subjectif (SDOWN) dans la plage de temps spécifiée, puis le serveur maître maître sera marqué comme objectif hors ligne (ODOWN) .
en général, chaque processus Sentinel envoie des commandes INFO à tous les serveurs maître et esclave du cluster à une fréquence d'une fois toutes les 10 secondes.
Lorsque le serveur maître maître est marqué comme objectivement hors ligne (ODOWN) par le processus Sentinel, la fréquence d'envoi des commandes INFO à partir de tous les serveurs esclaves du serveur maître maître que le processus Sentinel passe hors ligne passe d'une fois toutes les 10 secondes à toutes les deuxième.
S'il n'y a pas suffisamment de processus Sentinel pour accepter la mise hors ligne du serveur maître maître, l'état hors ligne objectif du serveur maître maître sera supprimé. Si le serveur maître maître envoie à nouveau une commande PING au processus Sentinel et renvoie une réponse valide, l'état hors ligne subjectif du serveur maître maître sera supprimé.
avantage:
Le mode sentinelle est basé sur le mode maître-esclave, tous les avantages du maître-esclave, le mode sentinelle a.
Le maître et l'esclave peuvent basculer automatiquement, le système est plus robuste et la convivialité est plus élevée.
Désavantages:
Redis est difficile à prendre en charge l'expansion en ligne, et l'expansion en ligne deviendra très compliquée lorsque la capacité du cluster atteindra la limite supérieure.
Phénomène du cerveau divisé:
Qu'est-ce que le cerveau divisé?
Le soi-disant problème du cerveau divisé (similaire à la schizophrénie) est que différents nœuds du même cluster ont une compréhension différente de l'état du cluster.
Pourquoi le redis split brain est-il causé par le mode sentinelle?
Par exemple (1 maître, 1 esclave, 2 sentinelle), pour des raisons de réseau ou pour des raisons spéciales, la sentinelle perd sa connaissance du périphérique du nœud maître et basculera via des élections pour promouvoir le nœud esclave vers le nœud maître, ce qui conduit à Il y a deux maîtres dans le groupe actuel, ce qui est une manifestation du phénomène du cerveau divisé. Différents clients sont liés à différents redis pour la lecture et l'écriture, alors les données redis sur les deux machines seront incohérentes. Lorsque la sentinelle restaure sa perception de l'ancien nœud maître, elle sera rétrogradée vers un nœud esclave, puis synchronisera les données du nouveau maste (resynchronisation complète), entraînant la perte des données écrites par l'ancien maître lors du split-brain point final.
solution
Redis.conf modifie les attributs pour limiter l'opération d'écriture du nœud maître par le nombre de nœuds esclaves actifs et le temps de retard de synchronisation des données.
# master Au moins x répliques sont connectées.
min-esclaves-à-écrire x
# Le délai de réplication et de synchronisation des données ne peut pas dépasser x secondes.
min-esclaves-max-lag x
Effet baril
3.
Le mode sentinelle du cluster Cluster Redis peut essentiellement atteindre une haute disponibilité et une séparation en lecture-écriture, mais dans ce mode, chaque serveur Redis stocke les mêmes données, ce qui est un gaspillage de mémoire, le mode Cluster cluster est donc ajouté à redis3. 0, il réalise le stockage distribué de Redis, ce qui signifie que différents contenus sont stockés sur chaque nœud Redis.
Configuration du cluster
Selon la recommandation officielle, un déploiement de cluster nécessite au moins 3 nœuds maîtres et il est préférable d'utiliser un modèle à six nœuds à 3 maîtres et à 3 esclaves. Dans l'environnement de test, seules 6 instances de service peuvent être ouvertes sur une machine à simuler.
Caractéristiques du cluster
Tous les nœuds redis sont interconnectés les uns avec les autres (mécanisme PING-PONG), et le protocole binaire est utilisé en interne pour optimiser la vitesse de transmission et la bande passante.
La défaillance d'un nœud prend effet uniquement lorsque plus de la moitié des nœuds du cluster détectent la défaillance.
Le client est directement connecté au nœud Redis et ne nécessite pas de couche proxy intermédiaire. Le client n'a pas besoin de se connecter à tous les nœuds du cluster, il suffit de se connecter à n'importe quel nœud disponible du cluster.
Tous les nœuds sont un maître et un esclave (ou un maître et plusieurs esclaves), qui ne fournissent jamais de services, ne servent que de sauvegarde
Prise en charge de l'ajout et de la suppression en ligne de nœuds
Le client peut se connecter à n'importe quel nœud maître pour lire et écrire
Comment fonctionne le cluster
Sur chaque nœud de Redis, il y a deux choses, l'une est un emplacement et sa plage de valeurs est comprise entre 0 et 16383. Il existe également un cluster, qui peut être compris comme un plug-in de gestion de cluster. Lorsque notre clé d'accès arrive, Redis obtiendra un résultat selon l'algorithme de crc16, puis calculera le reste du résultat à 16384, de sorte que chaque clé correspondra à un emplacement de hachage numéroté entre 0 et 16383, et passera cette valeur permet de trouver le nœud correspondant à l'emplacement correspondant, puis de sauter automatiquement au nœud correspondant pour les opérations d'accès.
Le cluster Redis utilise le partage de données au lieu du hachage de cohérence pour obtenir: Un cluster Redis contient 16384 emplacements de hachage, et chaque clé de la base de données appartient à ces 16384 emplacements de hachage L'un d'eux, le cluster utilise la formule CRC16 (clé)% 16384 pour calculer lequel emplacement auquel appartient la clé et l'instruction CRC16 (clé) est utilisée pour calculer la somme de contrôle CRC16 de la clé.
Chaque nœud du cluster est responsable du traitement d'une partie de l'emplacement de hachage. Par exemple, un cluster peut avoir trois emplacements de hachage, dont:
Le nœud A est responsable du traitement des emplacements de hachage 0 à 5500.
Le nœud B est responsable du traitement des emplacements de hachage 5501 à 11000.
Le nœud C est responsable du traitement des emplacements de hachage 11001 à 16384.
Cette méthode de distribution d'emplacements de hachage à différents nœuds permet aux utilisateurs d'ajouter ou de supprimer facilement des nœuds du cluster.
Afin d'assurer une haute disponibilité, le cluster redis-cluster introduit un mode 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 sont 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 en heures supplémentaires, alors on considère que le nœud maître A est arrêté. Si le nœud maître A et son nœud esclave A1 sont hors service, le cluster ne peut plus fournir de services.
La différence entre sentinelle et essaim
sentinelle
Le rôle de la sentinelle est de surveiller l'état de fonctionnement du système Redis. Ses fonctions comprennent les deux suivantes.
Vérifiez si la base de données principale et la base de données secondaire fonctionnent normalement.
Lorsque la base de données principale échoue, la base de données secondaire est automatiquement convertie en base de données principale.
Lorsque la sentinelle découvre que le maître est en panne, elle réélit un maître parmi les esclaves.
Le mode sentinelle souligne que le
système Sentinel hautement disponible est utilisé pour gérer plusieurs serveurs Redis (instance). Le système effectue les trois tâches suivantes:
Surveillance: Sentinel vérifiera en permanence si votre serveur maître et votre serveur esclave fonctionnent normalement.
Notification: en cas de problème avec un serveur Redis surveillé, Sentinel peut envoyer des notifications aux administrateurs ou à d'autres applications via l'API.
Basculement automatique: lorsqu'un serveur maître ne fonctionne pas normalement, Sentinel lance une opération de basculement automatique. Il met à niveau l'un des serveurs esclaves du serveur maître défaillant vers un nouveau serveur maître et laisse le serveur maître tomber en panne. Les autres serveurs esclaves sont modifiés pour répliquer le nouveau serveur maître; lorsque le client essaie de se connecter au serveur maître défaillant, le cluster renverra également l'adresse du nouveau serveur maître au client, afin que le cluster puisse utiliser le nouveau serveur maître pour remplacer le serveur défaillant .
Le client n'enregistre pas l'adresse de redis (une certaine IP), mais l'adresse de sentinel, afin que nous puissions obtenir l'adresse redis directement de sentinel, car sentinel surveille tous les maîtres et esclaves, et il sait qui exactement C'est le réel maître. Par exemple, nous basculons. À ce stade, pour la sentinelle, le maître a changé, puis le client est averti. Le client n'a pas du tout besoin de se soucier de qui est le vrai maître, seulement le maître informé par la sentinelle.
Grappe
Même si des sentinelles sont utilisées, chaque instance de redis est stockée dans son intégralité, et le contenu stocké dans chaque redis est des données complètes, ce qui gaspille de la mémoire et a un effet de barillet. Afin de maximiser l'utilisation de la mémoire, des clusters peuvent être utilisés, c'est-à-dire un stockage distribué. Autrement dit, chaque redis stocke un contenu différent, un total de 16384 emplacements. Chaque redis se voit attribuer des emplacements, hash_slot = crc16 (clé) mod 16384 pour trouver l'emplacement correspondant, la clé est la clé disponible, s'il y a {}, prenez le {} comme clé disponible, sinon la clé entière est la clé disponible le
cluster de clés nécessite au moins 3 maîtres 3 esclaves, et chaque instance utilise un fichier de configuration différent, le maître et l'esclave n'ont pas besoin d'être configurés, le cluster choisira par lui-même.
Le cluster doit résoudre le problème de la capacité limitée d'un seul Redis, et les données sont distribuées sur plusieurs machines selon certaines règles.
Le mode cluster augmente la quantité de concurrence.