Expliquer Apache ZooKeeper
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 le comprendre.
Je viens de lire à travers http://zookeeper.sourceforge.net/index.sf.shtml , n'y a-t-il donc pas d'autres services comme celui-ci? Est-ce aussi simple que de simplement reproduire un service serveur?
En résumé, ZooKeeper vous aide à créer des applications distribuées.
Comment ça fonctionne
Vous pouvez décrire ZooKeeper en tant que service de synchronisation répliqué avec une cohérence éventuelle. Il est robuste, car les données persistantes sont réparties entre plusieurs noeuds (cet ensemble de noeuds est appelé un "ensemble") et un client se connecte à l’un d’entre eux (c’est-à-dire un "serveur" spécifique), migrant si un noeud échoue; tant qu'une majorité stricte de nœuds fonctionnent, l'ensemble des nœuds ZooKeeper est actif. 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 du maître migre vers un autre nœud.
Comment les écritures sont gérées
Le maître est l’autorité pour les écritures: il est ainsi garanti que les écritures sont persistantes dans l’ordre, c’est-à-dire que les écritures sont linéaires . Chaque fois qu'un client écrit dans l'ensemble, une majorité de nœuds conservent les informations: 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 que vous ne pouvez pas avoir d’écritures simultanées.
La garantie des écritures linéaires est la raison pour laquelle ZooKeeper ne fonctionne pas correctement pour les charges de travail en écriture dominantes. En particulier, il ne devrait pas être utilisé pour l'échange de données volumineuses, telles que des supports. ZooKeeper vous aide dans la mesure où votre communication implique des données partagées. Lorsque des données peuvent être écrites simultanément, ZooKeeper est un obstacle, car il impose un ordre strict des opérations même s’il n’est pas strictement nécessaire du point de vue des auteurs. Son utilisation idéale est pour la coordination, où les messages sont échangés entre les clients.
Comment les lectures sont gérées
ZooKeeper excelle ici: 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 indé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 approximativement les nœuds du système de fichiers (considérez-les comme des répertoires). Chaque znode peut être enrichi par un tableau d'octets, qui stocke des données. De plus, chaque znode peut avoir d'autres znodes dessous, formant pratiquement un système d'annuaire interne.
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 indiqué par un numéro séquentiel choisi. par l'ensemble. Ceci est utile, par exemple, à des fins de synchronisation: si plusieurs clients veulent verrouiller une ressource, ils peuvent créer simultanément un znode séquentiel sur un emplacement: celui qui obtient le plus petit numéro 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 assumées 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.
Les montres
L'exemple lié à la déconnexion du client peut être problématique si nous devons interroger périodiquement l'état de znodes. Heureusement, ZooKeeper propose un système d’événements dans lequel une surveillance peut être définie sur un znode. Ces contrôles peuvent être configurés 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 des nœuds clients et doivent être consultées/mises à jour de manière très prudente pour prendre en compte la synchronisation.
ZooKeeper propose à la bibliothèque de 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 lors de l’utilisation d’un référentiel de messages centralisé (semblable à un courtier).
ZooKeeper est doté de nombreuses fonctionnalités, ce qui signifie que des mécanismes tels que l'élection du chef, 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 lourde pour vos besoins, vous devez vous fier aux bibliothèques construites sur ZooKeeper telles que cages et surtout curator .
Où lire plus
La documentation officielle mise à part, ce qui est plutôt bon, je suggère de lire le chapitre 14 de Hadoop: Le Guide définitif qui contient environ 35 pages expliquant essentiellement ce que fait ZooKeeper, suivi d’un exemple de service de configuration.
Zookeeper est l’un des meilleurs serveurs et services open source permettant de coordonner de manière fiable les processus distribués. Zookeeper est un système CP (voir le théorème CAP) qui fournit la cohérence et la tolérance de partition. La réplication de l'état de Zookeeper sur tous les nœuds en fait un service distribué cohérent.
De plus, tout dirigeant nouvellement élu mettra à jour ses partisans avec les propositions manquantes ou avec un instantané de l'état, si les partisans ont beaucoup de propositions manquantes.
Zookeeper fournit également une API très facile à utiliser. Cet article de blog, Zookeeper Java exemples d'API , contient des exemples si vous recherchez des exemples.
Alors, où utilisons-nous cela? Si votre service distribué nécessite une gestion de la configuration centralisée, fiable et cohérente, des verrous, des files d'attente, etc., Zookeeper constitue un choix fiable.
Je comprends le ZooKeeper en général mais des problèmes avec les termes "quorum" et "cerveau divisé" ont été rencontrés, alors je peux peut-être partager mes découvertes 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 pour savoir qui devrait être le chef".
Donc, le vote est basé sur la majorité. La majorité signifie simplement "plus de la moitié", donc plus de la moitié du nombre de serveurs doit accepter pour qu'un serveur spécifique devienne le leader.
Donc, il y a cette mauvaise chose qui peut arriver appelée "cerveau divisé". Un cerveau divisé est tout simplement ceci, pour autant que je sache: le cluster de 5 serveurs se scinde en deux parties, ou appelons-le "équipes de serveurs", avec peut-être une partie sur 2 et l'autre sur 3 serveurs. C'est vraiment une mauvaise situation car si les deux "équipes de serveurs" doivent exécuter un ordre spécifique, quelle décision choisiriez-vous? Ils ont peut-être 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 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" peuvent 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 composée de 3 serveurs est majoritaire et est autorisée à sélectionner le nouveau chef.
Même si vous n'avez que 3 serveurs et que l'un des deux échoue, 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.
Zookeeper est un serveur open source centralisé permettant de gérer et de gérer les informations de configuration, les conventions de dénomination et la synchronisation pour un environnement de cluster distribué. Zookeeper aide les systèmes distribués à réduire la complexité de leur gestion en offrant une faible latence et une haute disponibilité. Zookeeper était à l'origine un sous-projet pour Hadoop, mais il s'agit désormais d'un projet indépendant de niveau supérieur d'Apache Software Foundation.