Zookeeper est un sous-projet de Hadoop, et bien qu’il soit dérivé de Hadoop, j’ai constaté que Zookeeper utilise de plus en plus des frameworks distribués en dehors de Hadoop. Aujourd’hui, je veux parler de zookeeper, cet article ne parlera pas de la manière d’utiliser zookeeper, mais des applications pratiques de zookeeper, des types d’applications qui peuvent jouer les avantages de zookeeper, et enfin du rôle que zookeeper peut jouer dans l’architecture distribuée des sites web.
Zookeeper est un système de coordination hautement fiable pour les grands systèmes distribués. D’après cette définition, nous savons que le gardien de zoo est un système coordonné qui agit sur des systèmes distribués. Pourquoi les systèmes distribués ont-ils besoin d’un système de coordination ? Les raisons sont les suivantes :
Développer un système distribué est une tâche très difficile, et cette difficulté se reflète principalement dans la « défaillance partielle » du système distribué. « Défaillance partielle » fait référence à la transmission d’informations entre deux nœuds du réseau ; si le réseau tombe en panne, l’émetteur ne peut pas savoir si le récepteur a reçu le message, et la cause de cette défaillance est complexe, le récepteur peut ou non avoir reçu le message avant l’erreur réseau, ou le processus du récepteur est mort. La seule façon pour l’émetteur d’obtenir une image réelle est de se reconnecter au récepteur et de demander au récepteur pourquoi l’erreur s’est produite, ce qui est le problème de « défaillance partielle » dans le développement de systèmes distribués.
Zookeeper est le cadre pour résoudre la « défaillance partielle » des systèmes distribués. Zookeeper n’autorise pas les systèmes distribués à éviter les problèmes de « défaillance partielle », mais permet aux systèmes distribués de gérer correctement ces problèmes lors de défaillances partielles, afin que les systèmes distribués puissent fonctionner normalement.
Parlons de l’utilisation pratique du soigneur de zoo :
Scénario 1 : Il existe un groupe de serveurs qui fournissent un certain service au client (par exemple, le côté serveur du site distribué que j’ai créé plus tôt est un cluster composé de quatre serveurs pour fournir des services au cluster front-end), et nous espérons que le client pourra trouver un serveur dans le cluster de serveurs à chaque demande, afin que le serveur puisse fournir au client les services dont le client a besoin. Dans ce scénario, nous devons disposer d’une liste de serveurs dans notre programme, à partir de laquelle nous lisons la liste des serveurs à chaque demande du client. Ensuite, cette sous-liste ne peut évidemment pas être stockée sur un seul serveur de nœud, sinon le nœud se bloquera et tout le cluster échouera, et nous espérons que cette liste sera très disponible à ce moment-là. Si un serveur dans la liste de stockage est défectueux, d’autres serveurs peuvent immédiatement remplacer le serveur défectueux, et le serveur défaillant peut être retiré de la liste, de sorte que le serveur défaillant puisse se retirer de l’exploitation de l’ensemble du cluster, et toutes ces opérations ne seront pas opérées par le serveur défaillant, mais par le serveur normal du cluster. Il s’agit d’une structure de données distribuée active qui peut modifier activement l’état des éléments de données lorsque les conditions externes changent. Le cadre Zookeeper fournit ce service. Le nom de ce service est : Unified Naming Service, qui est très similaire au service JNDI en javaEE.
Scénario 2 : Service de serrure distribuée. Lorsqu’un système distribué manipule des données, comme la lecture des données, l’analyse des données, et enfin la modification des données. Dans le système distribué, ces opérations peuvent être dispersées entre différents nœuds du cluster, il y a alors un problème de cohérence dans le processus d’exploitation des données ; si c’est incohérent, nous obtiendrons un mauvais résultat d’opération, dans un seul programme à processus, le problème de cohérence est facile à résoudre, mais il est plus difficile d’atteindre le système distribué, car les opérations des différents serveurs dans le système distribué se déroulent dans des processus indépendants, et les résultats intermédiaires et processus de l’opération doivent être transmis via le réseau. Il devient alors beaucoup plus difficile d’obtenir la cohérence des opérations des données. Zookeeper propose un service de verrouillage qui résout ce problème, nous permettant d’assurer la cohérence des opérations de données lors des opérations de données distribuées.
Scénario 3 : Gestion de configuration. Dans un système distribué, nous déployons une application de service sur n serveurs séparément, et les fichiers de configuration de ces serveurs sont les mêmes (par exemple, dans le cadre de site distribué que j’ai conçu, il y a 4 serveurs côté serveur, les programmes sur les 4 serveurs sont les mêmes, et les fichiers de configuration sont les mêmes), si les options de configuration des fichiers de configuration changent, alors nous devons modifier ces fichiers un par un, si nous devons changer les serveurs sont relativement petits, ces opérations ne sont pas trop problématiques, Si nous disposons d’un grand nombre de serveurs distribués, comme le cluster Hadoop d’une grande entreprise Internet avec des milliers de serveurs, alors modifier les options de configuration peut être une chose problématique et dangereuse. À ce stade, zookeeper peut être très utile, nous pouvons utiliser zookeeper comme mémoire de configuration hautement disponible, transmettre ce type de contenu à zookeeper pour la gestion, copier le fichier de configuration du cluster vers un nœud du système de fichiers du zookeeper, puis utiliser zookeeper pour surveiller l’état du fichier de configuration dans tous les systèmes distribués, une fois que le fichier de configuration a changé, Chaque serveur recevra une notification de Zookeeper pour synchroniser les fichiers de configuration dans Zookeeper, et le service Zookeeper s’assurera également que l’opération de synchronisation est atomique afin de garantir que le fichier de configuration de chaque serveur soit correctement mis à jour.
Scénario 4 : Fournir des fonctions de réparation des pannes pour les systèmes distribués. La gestion du cluster est difficile, et ajouter le service de soigneur au système distribué facilite la gestion du cluster. La chose la plus problématique dans la gestion du cluster est la gestion des défauts de nœuds : zookeeper permet au cluster de sélectionner un nœud sain comme maître, le maître connaît l’état de santé actuel de chaque serveur dans le cluster, et dès qu’un nœud tombe en panne, le maître notifiera les autres serveurs du cluster afin de redistribuer les tâches de calcul des différents nœuds. Zookeeper peut non seulement trouver les défauts, mais aussi filtrer le serveur défectueux, voir quel type de défaut il s’agit, si le défaut peut être réparé, Zookeeper peut automatiquement corriger ou indiquer à l’administrateur système la raison de l’erreur, afin que l’administrateur puisse rapidement localiser le problème et réparer le défaut du nœud. Vous avez peut-être encore une question : que dois-je faire si le master est défectueux ? Zookeeper prend également cela en compte : zookeeper dispose d’un « algorithme interne pour élire les leaders », les maîtres peuvent être sélectionnés dynamiquement, et en cas d’échec, le gardien peut immédiatement sélectionner un nouveau maître pour gérer le cluster.
Parlons des caractéristiques du gardien de zoo :
ZooKeeper est un système de fichiers simplifié. C’est un peu similaire à Hadoop, mais le système de fichiers ZooKeeper gère de petits fichiers, tandis que Hadoop gère de très gros fichiers.
Zookeeper fournit une multitude d'« artefacts » qui permettent à de nombreuses opérations de coordonner des structures de données et des protocoles. Par exemple : files d’attente distribuées, verrous distribués, et l’algorithme de « sélection de leader » d’un groupe de nœuds au même niveau.
ZooKeeper est très disponible, sa propre stabilité est assez bonne, les clusters distribués peuvent compter sur la gestion des clusters Zookeeper, et ZooKeeper est utilisé pour éviter le problème de la défaillance ponctuelle unique des systèmes distribués.
Zookeeper adopte un mode d’interaction faiblement couplé. Cela est particulièrement évident dans le fait que zookeeper fournit des verrous distribués, qui peuvent être utilisés comme mécanisme de rendez-vous permettant aux processus participants de se découvrir et d’interagir sans connaître les autres processus (ou le réseau), et les parties participantes n’ont même pas besoin d’exister en même temps, tant qu’elles laissent un message dans Zookeeper, et qu’après la fin du processus, un autre processus peut lire ce message, découplant ainsi la relation entre les nœuds.
ZooKeeper fournit un dépôt partagé pour le cluster, à partir duquel le cluster peut lire et écrire des informations partagées de manière centralisée, évitant ainsi la programmation d’opérations partagées pour chaque nœud et réduisant la difficulté de développement des systèmes distribués.
Zookeeper est principalement responsable du stockage et de la gestion des données qui comptent pour tous, puis d’accepter l’enregistrement des observateurs ; une fois le statut de ces données modifié, Zookeeper sera chargé d’informer les observateurs inscrits sur Zookeeper pour qu’ils répondent en conséquence, afin d’atteindre un mode de gestion maître/esclave similaire à celui du cluster.
On constate que zookeeper est très propice au développement de systèmes distribués, ce qui peut rendre les systèmes distribués plus robustes et efficaces.
Il n’y a pas si longtemps, j’ai participé au groupe d’intérêt hadoop du département, j’ai installé hadoop, mapreduce, Hive et Hbase dans l’environnement test, et j’ai installé zookeeper à l’avance lors de l’installation de hbase. Zookeeper peut fournir des services, donc plus de la moitié des 3 correspondent à 2, et plus de la moitié des 4 sont aussi deux, donc installer trois serveurs peut obtenir l’effet de 4 serveurs. Dans le processus d’apprentissage de Hadoop, je pense que Zookeeper est le sous-projet le plus difficile à comprendre, la raison n’est pas qu’il soit techniquement responsable, mais que sa direction d’application me semble très confuse, donc mon premier article sur la technologie Hadoop commence avec Zookeeper, sans parler d’implémentations techniques spécifiques, mais d’après les scénarios d’application de Zookeeper, je comprends le domaine de l’application Zookeeper, je pense qu’apprendre Zookeeper sera plus efficace avec la moitié des efforts.
La raison pour laquelle je veux parler de zookeeper aujourd’hui est de compléter le cadre de site web distribué dans mon article précédent. Bien que j’aie conçu l’architecture du site web pour qu’elle soit distribuée, j’ai aussi mis en place un mécanisme simple de gestion des défauts, comme le mécanisme du battement cardiaque, mais il n’y a toujours aucun moyen de résoudre le point unique de défaillance du cluster : si un serveur est défectueux, le client tentera de se connecter à ce serveur, ce qui entraînera le blocage de certaines requêtes et conduit également au gaspillage des ressources serveur. Cependant, je ne souhaite pas modifier mon cadre pour le moment, car j’ai toujours le sentiment qu’ajouter un service de soigneur de zoo aux services existants affectera l’efficacité du site web. Heureusement, notre département a également identifié un tel problème : il développera un cadre puissant d’appels à distance, séparera la gestion du cluster et la gestion de la communication, et fournira des services efficaces et disponibles de manière centralisée.
Transféré de ttp://www.cnblogs.com/sharpxiajun/archive/2013/06/02/3113923.html |
Publié sur 18/07/2017 14:19:01
|
|
|
