Cet article parle du principe de Zookeeper. L'éditeur pense que c'est assez bon. Je le partagerai avec vous pour votre référence. Les détails sont les suivants:
Préface
Zookeeper est un service de coordination distribué open source créé par Yahoo et est une implémentation open source de Google Chubby. Les applications distribuées peuvent implémenter des fonctions telles que la publication / abonnement de données, l'équilibrage des charges, les services de dénomination, la coordination / notification distribuée, la gestion des cluster, l'élection maître, le verrouillage distribué et les files d'attente distribuées basées sur Zookeeper.
1. Introduction
Zookeeper est un service de coordination distribué open source créé par Yahoo et est une implémentation open source de Google Chubby. Les applications distribuées peuvent implémenter des fonctions telles que la publication / abonnement de données, l'équilibrage des charges, les services de dénomination, la coordination / notification distribuée, la gestion des cluster, l'élection maître, le verrouillage distribué et les files d'attente distribuées basées sur Zookeeper.
2. Concepts de base
Cette section présentera plusieurs concepts de base de Zookeeper. Ces concepts sont expliqués plus en profondeur plus tard sur Zookeeper, il est donc nécessaire de comprendre ces concepts à l'avance.
2.1 Rôles de cluster
Dans Zookeeper, il y a trois personnages:
Chef
Disciple
Observateur
Un cluster de gardien de zoo n'aura qu'un seul leader en même temps, et les autres seront suiveurs ou observateurs.
La configuration de Zookeeper est très simple. Le fichier de configuration (zoo.cfg) de chaque nœud est le même, et seul le fichier MyID est différent. La valeur de MyId doit être la partie {numérique} du serveur. {Numeric} dans zoo.cfg.
Exemple de contenu de fichier zoo.cfg:
Gardien de zoo
Exécutez le statut ZooKeeper-Server sur le terminal de la machine avec Zookeeper. Vous pouvez voir quel rôle le gardien de zoo du nœud actuel est (leader ou suiveur).
Gardien de zoo
Comme mentionné ci-dessus, le nœud-20-104 est le leader et le nœud-20-103 est le suiveur.
Zookeeper n'a que deux rôles: le leader et le suiveur par défaut, et aucun rôle d'observateur. Pour utiliser le mode observateur, ajoutez: peerType = Observer dans le fichier de configuration de tout nœud qui souhaite devenir un observateur et ajouter: Observer à la ligne de configuration du serveur configuré en mode observateur dans le fichier de configuration de tous les serveurs, par exemple:
server.1:localhost:2888:3888:observer
Toutes les machines du cluster Zookeeper sélectionnent une machine appelée "leader" via un processus électoral de leader. Le serveur Leader fournit des services de lecture et d'écriture au client.
Le suiveur et l'observateur peuvent fournir des services de lecture, mais pas des services d'écriture. La seule différence entre les deux est que la machine d'observateur ne participe pas au processus électoral du leader, ni ne participe à la stratégie "plus de la moitié de la stratégie d'écriture" d'écriture, afin que l'observateur puisse améliorer les performances de lecture du cluster sans affecter les performances de l'écriture.
2.2 Session
La session fait référence à une session client. Avant d'expliquer la session client, comprenons d'abord la connexion client. Dans ZooKeeper, une connexion client fait référence à une longue connexion TCP entre le client et le serveur ZooKeeper.
Le port de service par défaut de Zookeeper est 2181. Lorsque le client démarre, une connexion TCP sera établie avec le serveur. À partir du premier établissement de connexion, le cycle de vie de la session client commence également. Grâce à cette connexion, le client peut maintenir une session valide avec le serveur via la détection de battements de cœur et peut également envoyer des demandes au serveur ZooKeeper et accepter les réponses. Dans le même temps, il peut également recevoir des notifications d'événements de montre du serveur via cette connexion.
La valeur SessionTimeout de la session est utilisée pour définir l'heure du délai d'expiration d'une session client. Lorsque la connexion client est déconnectée en raison d'une pression excessive du serveur, d'une défaillance du réseau ou d'une déconnexion active du client, tant que le serveur du cluster peut être reconnecté dans le délai spécifié par SessionTimeout, la session précédemment créée est toujours valide.
2.3 Node de données (Znode)
Lorsque vous parlez de distribution, généralement "nœuds" se réfèrent à chaque machine qui forme un cluster. Le nœud de données dans Zookeeper fait référence à l'unité de données dans le modèle de données, appelé Znode. Zookeeper stocke toutes les données en mémoire. Le modèle de données est un arbre (arbre Znode). Le chemin divisé par des barres obliques (/) est un Znode, tel que / HBase / Master, où HBase et Master sont tous deux ZNodes. Chaque ZNODE enregistrera son propre contenu de données et une série d'informations d'attribut sera enregistrée.
Note:
Le Znode ici peut être compris à la fois comme un fichier dans UNIX et un répertoire dans UNIX. Parce que chaque Znode peut non seulement écrire des données elle-même (équivalent aux fichiers dans UNIX), mais également avoir des fichiers ou des répertoires de niveau suivant (équivalent aux répertoires d'Unix).
Dans Zookeeper, Znode peut être divisé en deux catégories: les nœuds persistants et les nœuds temporaires.
Nœud persistant
Le nœud soi-disant persistant signifie qu'une fois ce Znode créé, le Znode sera enregistré sur ZooKeeper à moins que le Znode ne soit supprimé activement.
Nœuds temporaires
Le cycle de vie d'un nœud temporaire est lié à la session client. Une fois la session client échoué, tous les nœuds temporaires créés par ce client seront supprimés.
De plus, ZooKeeper permet également aux utilisateurs d'ajouter un attribut spécial: séquentiel à chaque nœud. Une fois que le nœud est marqué de cet attribut, lorsque ce nœud est créé, Zookeeper ajoutera automatiquement un numéro entier après son nœud, qui est un nombre auto-inférentiel maintenu par le nœud parent.
Version 2.4
Les données sont stockées sur chaque Znode de Zookeeper. Correspondant à chaque Znode, Zookeeper maintient une structure de données appelée stat pour elle. STAT enregistre trois versions de données de ce Znode, à savoir la version (la version Znode actuelle), la cversion (la version actuelle du nœud enfant ZNODE) et l'aversion (la version actuelle ACL Znode).
2.5 Informations sur le statut
En plus de stocker le contenu des données, chaque Znode stocke également certaines informations d'état du Znode lui-même. Utilisez la commande get pour obtenir le contenu et les informations d'état d'un certain Znode en même temps. comme suit:
Gardien de zoo
Dans ZooKeeper, l'attribut de version est utilisé pour implémenter la «vérification de l'écriture» dans le mécanisme de verrouillage optimiste (pour assurer le fonctionnement atomique des données distribuées).
2.6 Opération de transaction
Dans Zookeeper, une opération qui peut modifier l'état du serveur ZooKeeper est appelée opération de transaction. Il comprend généralement des opérations telles que la création de nœuds de données et la suppression, la mise à jour du contenu des données, la création de session client et l'échec. Pour chaque demande de transaction, ZooKeeper lui attribuera un ID de transaction unique mondialement unique, représenté par ZXID, généralement un numéro 64 bits. Chaque ZXID correspond à une opération de mise à jour, à partir de laquelle Zookeeper peut indirectement identifier l'ordre global dans lequel ces demandes d'opération de transaction sont traitées.
2.7 Watcher
Watcher (écouteur d'événements) est une fonctionnalité très importante de Zookeeper. Zookeeper permet aux utilisateurs d'enregistrer certains observateurs sur des nœuds spécifiés et lorsque certains événements spécifiques sont déclenchés, le serveur ZooKeeper informera l'événement au client intéressé. Ce mécanisme est une caractéristique importante de Zookeeper pour mettre en œuvre des services de coordination distribués.
2,8 ACL
Zookeeper utilise la stratégie ACL (Control Lists) pour contrôler les autorisations. Zookeeper définit les 5 autorisations suivantes.
Créer: l'autorisation de créer des nœuds enfants.
Lire: Obtenez des autorisations sur les données du nœud et la liste des nœuds enfants.
Écrivez: l'autorisation de mettre à jour les données du nœud.
Supprimer: supprimer les autorisations des nœuds enfants.
Admin: Définissez les autorisations pour Node ACL.
Remarque: Créer et supprimer sont les deux contrôles d'autorisation pour les nœuds enfants.
3. Scénarios d'application typiques de Zookeeper
Zookeeper est un cadre de gestion et de coordination des données distribuées hautement disponibles. Sur la base de la mise en œuvre de l'algorithme ZAB, ce cadre peut assurer la cohérence des données dans un environnement distribué. Il est également basé sur cette fonctionnalité qui fait de Zookeeper un outil puissant pour résoudre le problème de cohérence distribué.
3.1 Publication des données et abonnement (Centre de configuration)
Publication de données et abonnement, le soi-disant centre de configuration, comme son nom l'indique, est que l'éditeur publie des données au nœud Zookeeper pour les abonnés aux données, atteignant ainsi le but d'obtenir dynamiquement des données et de réalisation de la gestion centralisée et de la mise à jour dynamique des informations de configuration.
Dans notre développement habituel du système d'application, nous rencontrons souvent cette exigence: certaines informations de configuration courantes sont nécessaires dans le système, telles que les informations de liste de machines, les informations de configuration de la base de données, etc. Ces informations de configuration globale ont généralement les trois fonctionnalités suivantes.
La quantité de données est généralement relativement faible.
Le contenu des données change dynamiquement au moment de l'exécution.
Toutes les machines du cluster sont partagées et la configuration est cohérente.
Ces informations de configuration globales peuvent être publiées sur ZooKeeper, permettant au client (machine à cluster) de s'abonner au message.
Il existe généralement deux modes de conception pour les systèmes de publication / d'abonnement, à savoir pousser et tirer.
PUSH: Le serveur envoie activement des mises à jour de données à tous les clients souscrits.
Pull: Le client initie activement une demande d'obtention des dernières données. Habituellement, le client adopte une méthode de sondage et de traction chronométrée.
Zookeeper utilise une combinaison de poussée et de traction. comme suit:
Le client souhaite que le serveur enregistre les nœuds auxquels il doit faire attention. Une fois que les données du nœud modifient, le serveur enverra une notification d'événement d'observation au client correspondant. Une fois que le client a reçu cette notification de message, elle doit activement aller sur le serveur pour obtenir les dernières données (combinées par push and pull).
3.2 Service de dénomination
Les services de dénomination sont également un type de scénario commun dans les systèmes distribués. Dans un système distribué, en utilisant un service de dénomination, les applications client peuvent obtenir des informations telles que l'adresse de la ressource ou du service, du fournisseur, etc. en fonction du nom spécifié. Les entités nommées peuvent généralement être des machines dans le cluster, des services fournis, des objets distants, etc. - nous pouvons collectivement les appeler des noms (nom).
Parmi eux, le plus courant est la liste d'adresses de service dans certains cadres de service distribués (tels que RPC, RMI). En créant des nœuds séquentiels dans ZOOKEEPR, il est facile de créer un chemin mondial unique, qui peut être utilisé comme nom.
Le service de dénomination de Zookeeper génère un identifiant mondialement unique.
3.3 Coordination / notification distribuée
Zookeeper a un enregistrement d'observateur unique et un mécanisme de notification asynchrone, qui peut bien réaliser la notification et la coordination entre différentes machines et même différents systèmes dans un environnement distribué, réalisant ainsi le traitement en temps réel des changements de données. La méthode d'utilisation est généralement que différents clients enregistrent le même Znode sur le ZK pour écouter les modifications de Znode (y compris le contenu de Znode lui-même et des nœuds enfants). Si le ZNODE change, tous les clients abonnés peuvent recevoir la notification d'observation correspondante et effectuer un traitement correspondant.
La coordination / notification distribuée de ZK est un moyen de communication courant entre les systèmes distribués et les machines.
3.3.1 Détection du battement de cœur
Le mécanisme de détection du rythme cardiaque entre les machines signifie que dans un environnement distribué, différentes machines (ou processus) doivent détecter si les autres fonctionnent normalement. Par exemple, la machine A doit savoir si la machine B s'exécute normalement. Dans le développement traditionnel, nous jugeons généralement si l'hôte peut se camionner directement. S'il est plus compliqué, nous établirons une longue connexion entre les machines et réaliserons la détection du rythme cardiaque des machines de niveau supérieur par le mécanisme de détection du rythme cardiaque inhérent de la connexion TCP. Ce sont des méthodes de détection de battements cardiaques très courantes.
Voyons comment utiliser ZK pour implémenter la détection du rythme cardiaque entre les machines distribuées (processus).
Sur la base des caractéristiques des nœuds temporaires de ZK, différents processus peuvent créer des nœuds enfants temporaires sous un nœud spécifié dans ZK. Différents processus peuvent directement juger si le processus correspondant est vivant en fonction de ce nœud enfant temporaire. De cette façon, la détection et le système détecté n'ont pas besoin d'être directement liés, mais sont associés à un certain nœud sur le ZK, réduisant considérablement le couplage du système.
3.3.2 Rapport d'avancement du travail
Dans un système de distribution de tâches commun, généralement après la distribution de la tâche à différentes machines pour exécution, il est nécessaire de signaler les progrès de l'exécution de sa tâche au système de distribution en temps réel. Cette fois, il peut être réalisé via ZK. Sélectionnez un nœud sur ZK, et chaque client de tâche crée des nœuds enfants temporaires sous ce nœud, afin que deux fonctions puissent être obtenues:
Déterminez si la machine à tâches survit en jugeant si le nœud temporaire existe.
Chaque machine à tâches rédigera ses progrès de l'exécution de la tâche vers ce nœud temporaire en temps réel afin que le système central puisse obtenir les progrès de l'exécution des tâches en temps réel.
3.4 Master Election
Peut être considéré comme le scénario d'application le plus typique de Zookeeper. Par exemple, l'élection de NameNode actif dans HDFS, l'élection de ResourceManager actif dans le fil et l'élection de Hmaster actif dans HBASE.
En réponse aux besoins de l'élection maître, nous pouvons généralement choisir la caractéristique principale de la clé dans les bases de données relationnelles courantes à implémenter: si les machines qui deviennent Masters insérent un enregistrement du même ID de clé primaire dans la base de données, la base de données nous aidera à effectuer des vérifications de conflit de clé primaire, c'est-à-dire qu'une seule machine peut insérer avec succès - puis, nous pensons que la machine client qui inserte avec succès les données dans la données devient le maître.
Le fait de s'appuyer sur les caractéristiques principales des clés des bases de données relationnelles peut en effet garantir que le seul maître est élu dans le cluster.
Mais que dois-je faire si le maître actuellement élu est mort? Qui me dira que le maître est mort? De toute évidence, la base de données relationnelle ne peut pas nous informer de cet événement. Mais Zookeeper peut le faire!
L'utilisation de la forte cohérence de Zookeepr peut garantir que la création de nœuds peut garantir une unicité globale dans une concurrence élevée distribuée,
C'est-à-dire que si plusieurs clients demandent à créer le même nœud temporaire en même temps, une seule demande client peut être créée avec succès à la fin. En utilisant cette fonctionnalité, les élections principales peuvent être facilement effectuées dans un environnement distribué.
La machine où se trouve le client qui a réussi le nœud devient le maître. Dans le même temps, d'autres clients qui n'ont pas réussi à créer le nœud enregistreront un observateur pour un changement de nœud enfant sur le nœud pour surveiller si la machine principale actuelle est vivante. Une fois que le maître actuel est découvert, d'autres clients seront réétés.
Cela permet l'élection dynamique du maître.
3,5 verrouillage distribué
Les verrous distribués sont un moyen de contrôler l'accès synchrone aux ressources partagées entre les systèmes distribués.
Les verrous distribués sont divisés en verrous exclusifs et verrous partagés.
3.5.1 verrouillage exclusif
Locks exclusifs (verrous x pour faire court), également appelés verrous d'écriture ou verrous exclusifs.
Si la transaction T1 ajoute un verrou exclusif à l'objet de données O1, alors pendant toute la période de verrouillage, seule la transaction T1 est autorisée à lire et à mettre à jour O1, et aucune autre transaction ne peut effectuer de type d'opération sur cet objet de données (l'objet ne peut pas être verrouillé) jusqu'à ce que T1 ne libère le verrouillage exclusif.
On peut voir que le cœur du verrou exclusif est de savoir comment s'assurer qu'une seule transaction acquiert actuellement le verrou, et une fois le verrouillage libéré, toutes les transactions en attente d'acquérir le verrou peuvent être averties.
Comment utiliser Zookeeper pour obtenir un verrouillage exclusif?
Définir le verrouillage
Un Znode sur Zookeeper peut représenter un verrou. Par exemple, le nœud / exclusive_lock / verrouillage peut être défini comme un verrou.
Obtenir le verrouillage
Comme mentionné ci-dessus, considérons un Znode sur Zookeeper comme verrouillage, et l'obtention du verrou est obtenu en créant un Znode. Tous les clients vont sur / exclusive_lock / Lock pour créer des nœuds enfants temporaires / exclusive_lock / Lock sous / exclusive_lock nœud. Zookeeper s'assurera que parmi tous les clients, un seul client peut être créé avec succès, puis il peut être considéré que le client a obtenu le verrou. Dans le même temps, tous les clients qui n'ont pas obtenu le verrou doivent enregistrer un observateur pour le nœud enfant changent sur le nœud / exclusive_lock pour écouter sur le nœud de verrouillage change en temps réel.
Relâchez le verrouillage
Parce que / exclusive_lock / Lock est un nœud temporaire, il est possible de libérer le verrou dans les deux cas.
Si la machine client obtient actuellement le verrouillage échoue ou redémarre, le nœud temporaire sera supprimé et le verrou sera libéré.
Une fois la logique métier exécutée normalement, le client supprimera activement le nœud temporaire qu'il a créé et libérera le verrou.
Peu importe dans quelles circonstances le nœud de verrouillage est supprimé, ZooKeeper informe tous les clients qui ont un changement de noeud enregistré à l'écoute du nœud / exclusive_lock. Après avoir reçu la notification, ces clients réinitient à nouveau l'acquisition de verrouillage distribuée, c'est-à-dire la répétition de "l'acquisition de serrures".
3.5.2 Verrouillage partagé
Locks partagés (serrures S, appelés verrous S), également appelés verrous en lecture. Si la transaction T1 ajoute un verrou partagé à l'objet de données O1, alors T1 ne peut lire que O1, et d'autres transactions peuvent également ajouter un verrou partagé à O1 en même temps (non exclusif). O1 ne peut être ajouté qu'à un verrou exclusif jusqu'à ce que tous les verrous partagés sur O1 soient libérés.
Résumé: plusieurs transactions peuvent obtenir un verrou partagé pour un objet en même temps (lire en même temps). S'il y a un verrou partagé, vous ne pouvez pas ajouter un verrou exclusif (car le verrou exclusif est un verrou d'écriture)
4. Application de Zookeeper dans de grands systèmes distribués
Les scénarios d'application typiques de Zookeeper ont été introduits plus tôt. Cette section introduira l'application de Zookeeper dans les produits de Big Data communs Hadoop et HBASE en tant qu'exemples pour aider tout le monde à mieux comprendre les scénarios d'application distribués de Zookeeper.
4.1 Application de Zookeeper à Hadoop
Dans Hadoop, Zookeeper est principalement utilisé pour implémenter HA (Disponibilité de Hive), y compris NAMANODODE de HDFS et HA de ResourceCanager de Yarn. Dans le même temps, dans le fil, ZOOKEEPR est également utilisé pour stocker l'état de fonctionnement de l'application.
Le principe de l'utilisation de ZooKeEn pour implémenter HA est le même dans NAMANODODE de HDFS et ResourceCanager de YARN, donc cette section l'introduit avec le fil comme exemple.
Gardien de zoo
Comme le montre la figure ci-dessus, le fil se compose principalement de quatre parties: ResourceManager (RM), Nodemanager (NM), ApplicationMaster (AM) et Container. Le plus au cœur d'eux est ResourceManager.
ResourceManager est responsable de la gestion unifiée et de l'allocation de toutes les ressources du cluster. Il reçoit également des informations sur les rapports de ressources de chaque nœud (nodemanager) et alloue ces informations à chaque application (gestionnaire d'applications) en fonction de certaines politiques. Il maintient les informations ApplicationMaster, les informations NodeManager et l'utilisation des ressources de chaque application.
Afin d'implémenter HA, plusieurs ressources de ressources doivent coexister (généralement deux), et un seul ResourceManager est à l'état actif, tandis que les autres sont à l'état de secours. Lorsque le nœud actif ne peut pas fonctionner correctement (comme les temps d'arrêt ou le redémarrage de la machine), la veille concurrendra pour générer un nouveau nœud actif.
4.2 Interrupteur principal et de sauvegarde
Jetons un coup d'œil à la façon dont le YARN met en œuvre le passage de maîtrise entre plusieurs ressources.
1. Créez un nœud de verrouillage. Sur ZooKeeper, il y aura un nœud de verrouillage A / Yarn-Leader-Election / AppCluster-Yarn. Lorsque tous les ResourceManagers sont démarrés, ils seront en compétition pour écrire un nœud enfant de verrouillage: / yarn-leader-election / appcluster-yarn / activeBreadcrumb. Ce nœud est un nœud temporaire.
ZOOKEEPR peut s'assurer qu'un seul ResourceManager peut être créé avec succès à la fin. Le ResourceManager qui a été créé avec succès sera commuté à l'état actif, tandis que ceux qui n'ont pas réussi seront passés à l'état de secours.
Gardien de zoo
Vous pouvez voir que ResourceManager2 dans le cluster est actif pour le moment.
Enregistrer le moniteur d'observateur
Tous les ResourceManagers dans les états de secours enregistreront un observateur pour le changement de nœud au nœud / yarn-leader-election / appcluster-yarn / activeBreadcrumb. En utilisant les caractéristiques des nœuds temporaires, vous pouvez rapidement détecter le fonctionnement de ResourceCanagers dans les états actifs.
Interrupteur principal et de sauvegarde
Lorsqu'un State ResourceManager active subit une exception telle qu'un temps d'arrêt ou un redémarrage, la session client connectée à ZooKeeper sera invalide, de sorte que le nœud / yarn-leader-election / appcluster-yarn / activeBreadcrumb sera supprimé. À l'heure actuelle, les autres ressources en statut de secours recevront la notification d'événement Watcher du serveur ZooKeeper, puis répéteront le fonctionnement de l'étape 1.
Ce qui précède est le processus d'utilisation de Zookeeper pour réaliser la commutation principale et de sauvegarde de ResourceManager, qui réalise le HA de ResourceManager.
Le principe de mise en œuvre du Namenode HA dans HDFS est le même que le principe de mise en œuvre du ResourceManager HA en fil. Son nœud de verrouillage est / hadoop-ha / mycluster / activeBreadcrumb.
4.3 ResourceManager Status Storage
Dans ResourceManager, RMStatestore peut stocker certaines informations sur l'état interne de RM, y compris les informations d'application et leurs tentatives, les jetons de délégation, les informations de version, etc. Il convient de noter que la plupart des informations d'État dans RMStatestore n'ont pas besoin d'être persistantes, car il est facile de les reconstruire à partir d'informations de contexte, telles que l'utilisation des ressources. Dans le schéma de conception du stockage, trois implémentations possibles sont fournies, respectivement comme suit.
Sur la base de la mise en œuvre de la mémoire, il est généralement utilisé pour le développement et les tests quotidiens.
Des implémentations basées sur le système de fichiers telles que HDFS.
Basé sur la mise en œuvre de Zookeeper.
Étant donné que la quantité de données de ces informations de l'État n'est pas très importante, Hadoop recommande officiellement qu'il réalise le stockage des informations de l'État basées sur Zookeeper. Sur ZooKeke, les informations d'état du ResourceManager sont stockées sous le nœud racine de / rmStore.
Gardien de zoo
Le nœud RMApproot stocke les informations liées à chaque application, et le RMDTSecretManagerRoot stocke les informations liées à la sécurité et à d'autres informations. Le ResourceManager de chaque état actif lit ces informations d'état de Zookeeper pendant la phase d'initialisation et continue de traiter en conséquence en fonction de ces informations d'état.
4.4 Résumé:
Les principales applications du zookeepr à Hadoop sont:
Ha de namenode en hdfs et ha de ResourceManager dans le fil.
Stocker des informations sur l'état de RMStatestore
5. Application de Zookeeper dans HBASE
HBASE utilise principalement Zookeeper pour réaliser les élections HMaster et la commutation maître-glissement, la tolérance aux défauts du système, la gestion de Rootregion, la gestion de l'état de la région et la distribution
Gestion des tâches SplitWal, etc.
5.1 Élection Hmaster et interrupteur de sauvegarde principale
Le principe de l'élection Hmaster et de la commutation de support de maître est le même que le principe HA de NameNode dans HDFS et ResourceManager dans le fil.
5.2 Tolérance aux erreurs du système
Lorsque HBASE est démarré, chaque Régionserver créera un nœud d'information sous le nœud / hbase / rs de ZooKeeper (ci-après, nous appelons ce nœud un "nœud d'état RS"), tel que / hbase / rs / [nom d'hôte]. Dans le même temps, HMMaster s'inscrira et écoutera ce nœud. Lorsqu'un Régionserver échoue, Zookeeper supprimera le nœud d'état RS correspondant au serveur Régionserver car il ne peut pas accepter son rythme cardiaque pendant une période (c'est-à-dire que la session n'est pas valide).
Dans le même temps, Hmaster recevra une notification NodeDelete de Zookeeper, la détection d'un nœud est donc déconnectée et commence immédiatement un travail tolérant aux pannes.
Pourquoi HBASE ne laisse-t-il pas directement HAMMER être responsable de la surveillance du région. Si Hmaster gère directement le statut du Régionserver à travers des mécanismes de battements cardiaques, à mesure que le cluster devient de plus en plus grand, la charge de gestion de Hmaster deviendra plus lourde et peut également échouer, de sorte que les données doivent être persistées. Dans ce cas, Zookeeper devient le choix idéal.
5.3 Gestion de Rootregion
Pour les clusters HBASE, les informations de localisation du stockage de données sont enregistrées sur la région des métadonnées, c'est-à-dire la Rootregion. Chaque fois que le client initie une nouvelle demande et doit connaître l'emplacement des données, il interroge le Rootregion, et le propre emplacement de Rootregion est enregistré sur ZooKeeper (par défaut, il est enregistré dans le nœud de zookeeper / hbase / méta-région).
Lorsque le Rootregion change, tel que le mouvement manuel de la région, l'équilibrage de rechargement ou une défaillance du serveur Rootregion, il peut détecter ce changement via Zookeeper et prendre une série de mesures de reprise après sinistre correspondantes pour garantir que le client peut toujours obtenir les informations correctes Rootregion.
5.4 Gestion de la région
Les régions de HBASE sont souvent modifiées. Les raisons de ces modifications sont les défaillances du système, l'équilibrage de la charge, la modification de la configuration, la division et la fusion de la région, etc. Une fois que la région se déplace, elle passe par le processus de hors ligne et en ligne.
Les données ne sont pas accessibles pendant la ligne hors ligne et ce changement d'état dans la région doit être connu au niveau mondial, sinon des exceptions transactionnelles peuvent se produire.
Pour les grands grappes HBASE, le nombre de régions peut atteindre 100 000, voire plus. C'est également un bon choix de quitter la direction de la région de l'État à cette échelle à Zookeeper.
5.5 Gestion des tâches divisées distribuées
Lorsqu'un serveur Regionserver raccroche, car il y a toujours une partie des données nouvellement écrites qui n'ont pas été persistées dans le HFILE, lors de la migration du service Regionerver, une tâche importante consiste à restaurer cette partie des données qui sont encore en mémoire du WAL. L'étape la plus critique de cette partie du travail est SplitWal, c'est-à-dire que le HMMaster doit traverser le WAL du serveur Regionserver, le diviser en petits morceaux et le déplacer vers la nouvelle adresse et rejouer le journal.
Étant donné que le volume de journal d'un seul sert de région est relativement important (il peut y avoir des milliers de régions, avec GB de journaux), les utilisateurs espèrent souvent que le système peut rapidement terminer les travaux de récupération de journaux. Par conséquent, une solution réalisable consiste à allouer cette tâche qui gère le WAL à plusieurs serveurs de servants Régionserver pour le co-traitement, ce qui nécessite un composant persistant pour aider HHMaster à terminer l'allocation des tâches.
La pratique actuelle est que HMMaster créera un nœud SplitWal sur ZooKeeper (par défaut, c'est / HBase / SplitWal Node), de stocker des informations telles que "quel Regionserver s'occupe de la région" sur le nœud dans une liste, puis chaque serveur Regionerver ira au nœud pour collecter la tâche et mettre à jour les étapes du nœud après l'exécution de la tâche ou n'a pas réussi à notifier Hmmaster pour poursuivre les étapes des sous-prochains. Zookeeper joue le rôle de la notification mutuelle et de la persistance des informations dans les grappes distribuées ici.
5.6 Résumé:
Ce qui précède sont quelques scénarios typiques dans HBASE qui reposent sur Zookeeper pour remplir les fonctions de coordination distribuées. Mais en fait, HBASE a plus que cette dépendance à l'égard de Zookeeper. Par exemple, Hmaster s'appuie également sur ZooKeeper pour terminer l'enregistrement d'état Activer / Désactiver de la table, et presque tous les stockages de métadonnées dans HBASE sont placés sur Zookeeper.
En raison des excellentes capacités de coordination distribuées de Zookeeper et du bon mécanisme de notification, HBASE a de plus en plus ajouté des scénarios d'application ZooKeeper dans l'évolution de chaque version, et d'un point de vue tendance, les deux ont de plus en plus d'intersections. Toutes les opérations sur ZooKeeper dans HBASE sont encapsulées dans le package org.apache.hadoop.hbase.zookeeper. Les étudiants intéressés peuvent l'étudier eux-mêmes.
Ce qui précède est le module Spring Boot que l'éditeur vous a présenté. J'espère que cela vous sera utile. Si vous avez des questions, laissez-moi un message et l'éditeur vous répondra à temps!