Explication de Apache ZooKeeper

Question

J'essaie de comprendre ZooKeeper, comment il 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 capable de m'y retrouver.

Je viens de lire http://zookeeper.sourceforge.net/index.sf.shtml Il n'y a donc pas plus de services de ce type ? Est-ce aussi simple que de répliquer un service de serveur ?

Answer 1

En un mot, ZooKeeper vous aide à construire des applications distribuées.

Comment cela fonctionne

Vous pouvez décrire ZooKeeper comme un service de synchronisation répliqué avec une cohérence éventuelle. Il est robuste, puisque les données persistantes sont distribuées entre plusieurs nœuds (cet ensemble de nœuds est appelé "ensemble") et qu'un client se connecte à n'importe lequel d'entre eux (c'est-à-dire à un "serveur" spécifique), migrant si un nœud tombe en panne ; tant qu'une stricte majorité de nœuds fonctionne, l'ensemble de nœuds ZooKeeper est vivant. En particulier, un nœud maître est dynamiquement choisi 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 traitées

Le maître est l'autorité pour les écritures : de cette façon, on peut garantir que les écritures sont persistées dans l'ordre, c'est-à-dire que les écritures sont lineal . Chaque fois qu'un client écrit dans l'ensemble, une majorité de nœuds persistent l'information : ces nœuds incluent le serveur pour le client, et évidemment 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 concurrentes.

La garantie d'écritures linéaires est la raison pour laquelle ZooKeeper n'est pas performant pour les charges de travail à dominante d'écriture. En particulier, il ne devrait pas être utilisé pour l'échange de données volumineuses, comme les médias. 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 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 écrivains. Son utilisation idéale est pour la coordination, où des messages sont échangés entre les clients.

Comment les lectures sont traitées

C'est là que ZooKeeper excelle : les lectures sont concurrentes puisqu'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 périmée, puisque le maître met à jour le serveur correspondant avec un délai limité mais indéfini.

En détail

La base de données répliquée de ZooKeeper comprend un arbre 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 d'un tableau d'octets, qui stocke les données. De plus, chaque znode peut avoir d'autres znodes sous lui, formant pratiquement un système de répertoire interne.

Znodes séquentiels

Il est intéressant de noter que le nom d'un znode peut être séquentiel , ce qui signifie que le nom que le client fournit 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. Ceci est utile, par exemple, à des fins de synchronisation : si plusieurs clients veulent obtenir un verrou sur une ressource, ils peuvent chacun créer simultanément un znode séquentiel sur un emplacement : celui qui obtient le plus petit nombre a droit au verrou.

Znodes éphémères

De même, 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 reprenant l'exemple du verrou, dès que le client possédant 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 pourrait être problématique si nous devions interroger périodiquement l'état des znodes. Heureusement, ZooKeeper offre un système d'événements où une icône regarder peuvent être définies sur un znode. Ces veilles 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 lui. 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 de l'utilisation de Zookeeper est le calcul en mémoire distribuée, où certaines données sont partagées entre des noeuds clients et doivent être accédées/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 du point de défaillance unique que vous rencontrez lorsque vous utilisez un dépôt de messages centralisé (de type courtier).

ZooKeeper est feature-light, ce qui signifie que les mécanismes tels que l'élection du leader, les verrous, les barrières, etc. ne sont pas déjà présents, mais peuvent être écrits au-dessus des primitives de ZooKeeper. Si l'API C/Java est trop lourde pour vos besoins, vous devriez vous fier aux bibliothèques construites sur ZooKeeper telles que cages et surtout curateur .

Où lire la suite

En dehors de la documentation officielle, qui est assez bonne, je suggère de lire le chapitre 14 de Hadoop : Le Guide Définitif qui contient ~35 pages expliquant essentiellement ce que fait ZooKeeper, suivi d'un exemple de service de configuration.

Answer 2

Voici un Une présentation technique qui est une introduction à Apache ZooKeeper. par Camille Fournier qui est le directeur technique de RentTheRunway. J'espère qu'il vous sera utile.

Answer 3

Vous pouvez lire ce document

ZooKeeper : Coordination sans attente pour les systèmes à l'échelle d'Internet

Écrit par deux ingénieurs de Yahoo !

Answer 4

Zookeeper est l'un des meilleurs serveurs et services open source qui permet de coordonner de manière fiable des processus distribués. Zookeeper est un système CP (Refer CAP Theorem) qui assure la cohérence et la tolérance aux partitions. La réplication de l'état de Zookeeper sur tous les nœuds en fait un service distribué cohérent.

De plus, tout leader nouvellement élu mettra à jour ses suiveurs avec les propositions manquantes ou avec un instantané de l'état, si les suiveurs ont beaucoup de propositions manquantes.

Zookeeper fournit également une API qui est très facile à utiliser. Cet article de blog, Exemples d'API Java Zookeeper a quelques exemples si vous cherchez des exemples.

Alors, où l'utiliser ? Si votre service distribué a besoin d'une gestion centralisée, fiable et cohérente de la configuration, des verrous, des files d'attente, etc., vous trouverez en Zookeeper un choix fiable.

Answer 5

Je comprends le ZooKeeper en général, mais j'ai eu des problèmes avec les termes "quorum" et "split brain". Je peux donc peut-être partager mes découvertes avec vous (je me considère également comme un profane).

Disons que nous avons un cluster ZooKeeper de 5 serveurs. L'un des serveurs deviendra le leader et les autres seront les suiveurs.

• Ces 5 serveurs forment un quorum. Le quorum signifie simplement que "ces serveurs peuvent voter pour déterminer qui doit être le chef".

• Le vote est donc basé sur la majorité. Majorité signifie simplement "plus de la moitié", donc plus de la moitié du nombre de serveurs doit être d'accord pour qu'un serveur spécifique devienne le leader.

• Il y a donc cette mauvaise chose qui peut se produire appelée "cerveau divisé". Un cerveau divisé est simplement ceci, d'après ce 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écider quelle équipe doit être privilégiée ? Ils peuvent avoir reçu des informations différentes de la part des clients. Il est donc très important de savoir quelle "équipe de serveurs" est toujours pertinente et laquelle peut/doit être ignorée.

• La majorité est également la raison pour laquelle vous devriez utiliser un nombre impair de serveurs. Si vous avez 4 serveurs et un cerveau divisé où 2 serveurs se séparent alors les deux "équipes de serveurs" pourraient dire "hey, nous voulons décider qui est le leader !" mais comment décider quels sont les 2 serveurs que vous devez choisir ? Avec 5 serveurs, c'est simple : L'équipe de serveurs avec 3 serveurs a la majorité et est autorisée à choisir le nouveau leader.

• Même si vous n'avez que 3 serveurs et que l'un d'entre eux échoue, les 2 autres forment toujours la majorité et peuvent convenir que l'un d'entre eux deviendra le nouveau leader.

Je me rends compte qu'une fois que l'on y a réfléchi un peu et que l'on a compris les termes, ce n'est plus si compliqué. J'espère que cela aidera également quiconque à comprendre ces termes.