J'essaie de comprendre ZooKeeper, comment cela fonctionne et ce qu'il fait. Existe-t-il une application comparable à ZooKeeper?
Si vous le savez, comment décririez-vous ZooKeeper à un profane?
J'ai essayé apache wiki, zookeeper sourceforge ... mais je ne suis toujours pas en mesure de m'identifier à lui.
Je viens de lire à travers http://zookeeper.sourceforge.net/index.sf.shtml , donc n'y a-t-il pas d'autres services comme celui-ci? Est-ce aussi simple que de simplement répliquer un service serveur?
apache-zookeeper
distributed-computing
topgun_ivard
la source
la source
Réponses:
En un mot, ZooKeeper vous aide à créer des applications distribuées.
Comment ça fonctionne
Vous pouvez décrire ZooKeeper comme un service de synchronisation répliqué avec une cohérence éventuelle. Il est robuste, car les données persistantes sont réparties entre plusieurs nœuds (cet ensemble de nœuds est appelé un "ensemble") et un client se connecte à l'un d'entre eux (c'est-à-dire un "serveur" spécifique), migrant en cas de défaillance d'un nœud; tant qu'une stricte majorité des nœuds fonctionnent, l'ensemble des nœuds ZooKeeper est vivant. En particulier, un nœud maître est choisi dynamiquement par consensus au sein de l'ensemble; si le nœud maître échoue, le rôle de maître migre vers un autre nœud.
Comment les écritures sont gérées
Le maître est l'autorité pour les écritures: de cette façon, les écritures peuvent être garanties pour être persistantes dans l'ordre, c'est-à-dire que les écritures sont linéaires . Chaque fois qu'un client écrit à l'ensemble, une majorité de nœuds persistent dans l'information: ces nœuds incluent le serveur du client, et bien sûr le maître. Cela signifie que chaque écriture met le serveur à jour avec le maître. Cela signifie également, cependant, que vous ne pouvez pas avoir d'écritures simultanées.
La garantie des écritures linéaires est la raison du fait que ZooKeeper ne fonctionne pas bien pour les charges de travail dominantes en écriture. En particulier, il ne doit pas être utilisé pour l'échange de données volumineuses, telles que des supports. Tant que votre communication implique des données partagées, ZooKeeper vous aide. Lorsque les données peuvent être écrites simultanément, ZooKeeper se met réellement en travers du chemin, car il impose un ordre strict des opérations même si ce n'est pas strictement nécessaire du point de vue des rédacteurs. Son utilisation idéale est pour la coordination, où les messages sont échangés entre les clients.
Comment les lectures sont gérées
C'est là que ZooKeeper excelle: les lectures sont simultanées car elles sont servies par le serveur spécifique auquel le client se connecte. Cependant, c'est aussi la raison de la cohérence éventuelle: la "vue" d'un client peut être obsolète, car le maître met à jour le serveur correspondant avec un délai limité mais non défini.
En détail
La base de données répliquée de ZooKeeper comprend une arborescence de znodes , qui sont des entités représentant grossièrement les nœuds du système de fichiers (pensez-y comme des répertoires). Chaque znode peut être enrichi par un tableau d'octets, qui stocke les données. De plus, chaque znode peut avoir d'autres znodes en dessous, formant pratiquement un système de répertoires internes.
Znodes séquentiels
Fait intéressant, le nom d'un znode peut être séquentiel , ce qui signifie que le nom fourni par le client lors de la création du znode n'est qu'un préfixe: le nom complet est également donné par un numéro séquentiel choisi par l'ensemble. Cela est utile, par exemple, à des fins de synchronisation: si plusieurs clients souhaitent obtenir un verrou sur une ressource, ils peuvent chacun créer simultanément un znode séquentiel sur un emplacement: celui qui obtient le numéro le plus bas a droit au verrou.
Znodes éphémères
De plus, un znode peut être éphémère : cela signifie qu'il est détruit dès que le client qui l'a créé se déconnecte. Ceci est principalement utile pour savoir quand un client échoue, ce qui peut être pertinent lorsque le client lui-même a des responsabilités qui devraient être prises par un nouveau client. En prenant l'exemple du verrou, dès que le client ayant le verrou se déconnecte, les autres clients peuvent vérifier s'ils ont droit au verrou.
Montres
L'exemple lié à la déconnexion du client peut être problématique si nous avions besoin d'interroger périodiquement l'état des znodes. Heureusement, ZooKeeper propose un système d'événements où une montre peut être réglée sur un znode. Ces montres peuvent être définies pour déclencher un événement si le znode est spécifiquement modifié ou supprimé ou si de nouveaux enfants sont créés sous celui-ci. Ceci est clairement utile en combinaison avec les options séquentielles et éphémères pour les znodes.
Où et comment l'utiliser
Un exemple canonique d'utilisation de Zookeeper est le calcul à mémoire distribuée, où certaines données sont partagées entre les nœuds clients et doivent être accessibles / mises à jour de manière très prudente pour tenir compte de la synchronisation.
ZooKeeper offre la bibliothèque pour construire vos primitives de synchronisation, tandis que la possibilité d'exécuter un serveur distribué évite le problème de point de défaillance unique que vous rencontrez lorsque vous utilisez un référentiel de messages centralisé (de type courtier).
ZooKeeper est très léger, ce qui signifie que les mécanismes tels que l'élection des leaders, les verrous, les barrières, etc. ne sont pas déjà présents, mais peuvent être écrits au-dessus des primitives ZooKeeper. Si l'API C / Java est trop encombrante pour vos besoins, vous devez vous fier à des bibliothèques basées sur ZooKeeper telles que des cages et en particulier un conservateur .
Où en savoir plus
À part la documentation officielle, qui est plutôt bonne, je suggère de lire le chapitre 14 de Hadoop: le guide définitif qui compte environ 35 pages expliquant essentiellement ce que fait ZooKeeper, suivi d'un exemple de service de configuration.
la source
Zookeeper est l'un des meilleurs serveurs et services open source qui aide à coordonner de manière fiable les processus distribués. Zookeeper est un système CP (reportez-vous au théorème CAP) qui fournit une cohérence et une tolérance de partition. La réplication de l'état de Zookeeper sur tous les nœuds en fait un service distribué finalement cohérent.
De plus, tout leader nouvellement élu mettra à jour ses partisans avec des propositions manquantes ou avec un instantané de l'État, si les partisans ont de nombreuses propositions manquantes.
Zookeeper fournit également une API très simple à utiliser. Cet article de blog, des exemples d'API Java Zookeeper , contient des exemples si vous recherchez des exemples.
Alors, où utilisons-nous cela? Si votre service distribué a besoin d'une gestion de configuration centralisée, fiable et cohérente, de verrous, de files d'attente, etc., vous trouverez Zookeeper un choix fiable.
la source
Je comprends le ZooKeeper en général, mais j'ai eu des problèmes avec les termes "quorum" et "split brain" alors je peux peut-être partager mes résultats avec vous (je me considère aussi comme un profane).
Disons que nous avons un cluster ZooKeeper de 5 serveurs. L'un des serveurs deviendra le leader et les autres deviendront des suiveurs.
Ces 5 serveurs forment un quorum. Le quorum signifie simplement "ces serveurs peuvent voter sur qui devrait être le leader".
Le vote est donc basé sur la majorité. La majorité signifie simplement "plus de la moitié", donc plus de la moitié du nombre de serveurs doit accepter qu'un serveur spécifique devienne le leader.
Il y a donc cette mauvaise chose qui peut arriver, appelée "split brain". Un cerveau divisé est simplement ceci, pour autant que je comprends: le cluster de 5 serveurs se divise en deux parties, ou appelons-le "équipes de serveurs", avec peut-être une partie de 2 et l'autre de 3 serveurs. C'est vraiment une mauvaise situation car si les deux "équipes de serveurs" doivent exécuter un ordre spécifique, comment décideriez-vous quelle équipe devrait être préférée? Ils peuvent avoir reçu des informations différentes des clients. Il est donc très important de savoir quelle "équipe serveur" est toujours pertinente et laquelle peut / doit être ignorée.
La majorité est également la raison pour laquelle vous devez utiliser un nombre impair de serveurs. Si vous avez 4 serveurs et un cerveau divisé où 2 serveurs sont séparés, les deux "équipes de serveurs" pourraient dire "hé, nous voulons décider qui est le leader!" mais comment choisir les 2 serveurs à choisir? Avec 5 serveurs, c'est simple: l'équipe de serveurs avec 3 serveurs a la majorité et est autorisée à sélectionner le nouveau leader.
Même si vous n'avez que 3 serveurs et que l'un d'entre eux tombe en panne, les 2 autres forment toujours la majorité et peuvent convenir que l'un d'eux deviendra le nouveau leader.
Je me rends compte une fois que vous y réfléchissez un peu et comprenez les termes, ce n'est plus si compliqué. J'espère que cela aide également quiconque à comprendre ces termes.
la source
Zookeeper est un serveur open source centralisé pour la maintenance et la gestion des informations de configuration, les conventions de dénomination et la synchronisation pour l'environnement de cluster distribué. Zookeeper aide les systèmes distribués à réduire leur complexité de gestion en fournissant une faible latence et une haute disponibilité. Zookeeper était initialement un sous-projet pour Hadoop mais maintenant c'est un projet indépendant de haut niveau d'Apache Software Foundation.
Plus d'information
la source
Je suggère les ressources suivantes:
Je suggère de regarder la vidéo, de lire le journal, puis de revoir la vidéo. Ce serait plus facile à comprendre si vous connaissez Raft au préalable.
la source