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.