Expliquer Apache ZooKeeper


376

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?


6
Semblable mais pas à la réponse exacte que vous recherchez: stackoverflow.com/questions/1479442/real-world-use-of-zookeeper
zengr


Vous pouvez lire cet article ZooKeeper: Coordination sans attente pour les systèmes à l'échelle d'Internet Écrit par deux Yahoo! ingénieurs
yaphet

Voici une conférence technique qui est une introduction à Apache ZooKeeper par Camille Fournier qui est le CTO de RentTheRunway. J'espère que c'est utile.
Genadinik

@Luca Geretti ... Selon moi, Zookeper fournit un ensemble d'apis afin que nous puissions l'utiliser pour coordonner l'application distribuée. Corrigez-moi si je me trompe.
user3797438

Réponses:


434

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.


2
Je ne suis pas sûr de comprendre le schéma de communication que vous proposez, mais vous pouvez utiliser ZooKeeper pour "publier" les informations d'un producteur et demander à plusieurs consommateurs de les lire. Si par contre il n'existe qu'une seule instance de chaque type de serveur, il y a peu d'avantages à utiliser ZK.
Luca Geretti

58
OMI, cela ne permet pas d'expliquer ce qu'est ZooKeeper à un profane. Quand aurais-je besoin de ZooKeeper? Que devrais-je lui écrire? Quel problème résout-il? S'agit-il d'un magasin de valeurs-clés? Un moteur de recherche? Un verrou distribué? Pourquoi devrais-je choisir ZooKeeper par exemple Redis ou un fichier ou JIRA ou des post-it? Vous en savez clairement beaucoup sur ZooKeeper - mais pouvez-vous l'expliquer moins techniquement?
Dan Passaro

1
Comme Zookeeper a des écritures linéaires, cela ne m'empêche pas d'utiliser des API asynchrones pour créer des nœuds et prendre la réponse dans un rappel? Bien qu'en interne, il peut ne pas autoriser les écritures simultanées, ou manque-t-il quelque chose?
jdk2588

1
"Chaque fois qu'un client écrit à l'ensemble, une majorité de nœuds persistent dans l'information: ces nœuds incluent le serveur pour le client, et évidemment le maître" => pourriez-vous s'il vous plaît me pointer vers un doc. ou quelque chose où cela est expliqué? Je me demande s'il est possible qu'un changement d'état ait été effectué avec succès en excluant le serveur auquel le client est connecté (dans ce cas, le client peut rencontrer l'étrange comportement de ne pas pouvoir lire sa propre écriture pendant un moment)
senseiwu

3
Complètement et totalement antithétique à la question posée. S'il s'agissait d'une horloge, il chercherait un "dispositif de chronométrage" et non une description du ressort moteur, du train de roues, de l'échappement et de leur interaction en fonction de la période d'oscillation, du moment d'inertie et de l'impact des cristaux de saphir artificiels.
Rick O'Shea

10

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.


4
"Zookeeper est un système CP (reportez-vous au théorème CAP) qui fournit une tolérance de cohérence et de partition", je pense que Zookeeper a un maître et des suiveurs, lorsque le maître est en panne, alors l'un des suiveurs serait élu chef, donc Zookeeper devrait fournir le AP, cependant le C est finalement cohérent.
YuFeng Shen

5
En termes de théorème de CAP, "C" signifie en fait la linéarisation. ZooKeeper fournit en fait une «cohérence séquentielle» et cela signifie que les mises à jour des clients seront appliquées dans l'ordre dans lequel elles ont été reçues. Zookeeper n'est pas A et c'est parce que si le leader ne peut pas être élu (pas de quorum), alors zookeeper échouera aux demandes. C'est pourquoi il n'est pas très disponible.
Binu George

7

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.


1

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


3
Qu'est-ce qui vous fait dire que zookeeper est centralisé? Zookeeper peut et doit être exécuté distribué.
Benjamin Hammer Nørgaard

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.