Zookeeper - Principes de base

Avant d'approfondir le fonctionnement de ZooKeeper, examinons les concepts fondamentaux de ZooKeeper. Nous aborderons les sujets suivants dans ce chapitre -

  • Architecture
  • Espace de noms hiérarchique
  • Session
  • Watches

Architecture de ZooKeeper

Jetez un œil au diagramme suivant. Il décrit «l'architecture client-serveur» de ZooKeeper.

Chacun des composants faisant partie de l'architecture ZooKeeper a été expliqué dans le tableau suivant.

Partie La description
Client

Les clients, l'un des nœuds de notre cluster d'applications distribuées, accèdent aux informations du serveur. Pour un intervalle de temps particulier, chaque client envoie un message au serveur pour informer le serveur que le client est actif.

De même, le serveur envoie un accusé de réception lorsqu'un client se connecte. S'il n'y a pas de réponse du serveur connecté, le client redirige automatiquement le message vers un autre serveur.

Serveur Server, l'un des nœuds de notre ensemble ZooKeeper, fournit tous les services aux clients. Donne un accusé de réception au client pour l'informer que le serveur est actif.
Ensemble Groupe de serveurs ZooKeeper. Le nombre minimum de nœuds requis pour former un ensemble est de 3.
Chef Nœud de serveur qui effectue une récupération automatique en cas de défaillance de l'un des nœuds connectés. Les dirigeants sont élus au démarrage du service.
Disciple Nœud de serveur qui suit les instructions du leader.

Espace de noms hiérarchique

Le diagramme suivant illustre l'arborescence du système de fichiers ZooKeeper utilisé pour la représentation de la mémoire. Le nœud ZooKeeper est appeléznode. Chaque znode est identifié par un nom et séparé par une séquence de chemin (/).

  • Dans le diagramme, vous avez d'abord une racine znodeséparé par "/". Sous root, vous avez deux espaces de noms logiquesconfig et workers.

  • le config l'espace de noms est utilisé pour la gestion centralisée de la configuration et workers l'espace de noms est utilisé pour la dénomination.

  • En dessous de confignamespace, chaque znode peut stocker jusqu'à 1 Mo de données. Ceci est similaire au système de fichiers UNIX sauf que le znode parent peut également stocker des données. L'objectif principal de cette structure est de stocker des données synchronisées et de décrire les métadonnées du znode. Cette structure est appelée commeZooKeeper Data Model.

Chaque znode du modèle de données ZooKeeper maintient un statstructure. Une statistique fournit simplement lemetadatad'un znode. Il se compose du numéro de version, de la liste de contrôle des actions (ACL), de l'horodatage et de la longueur des données.

  • Version number- Chaque znode a un numéro de version, ce qui signifie que chaque fois que les données associées au znode changent, son numéro de version correspondant augmente également. L'utilisation du numéro de version est importante lorsque plusieurs clients zookeeper tentent d'effectuer des opérations sur le même znode.

  • Action Control List (ACL)- ACL est essentiellement un mécanisme d'authentification pour accéder au znode. Il régit toutes les opérations de lecture et d'écriture de znode.

  • Timestamp- L'horodatage représente le temps écoulé depuis la création et la modification de znode. Il est généralement représenté en millisecondes. ZooKeeper identifie chaque modification apportée aux znodes à partir de «Transaction ID» (zxid).Zxid est unique et maintient l'heure de chaque transaction afin que vous puissiez facilement identifier le temps écoulé d'une demande à une autre.

  • Data length- La quantité totale de données stockées dans un znode correspond à la longueur des données. Vous pouvez stocker un maximum de 1 Mo de données.

Types de Znodes

Les znodes sont classés en persistance, séquentiel et éphémère.

  • Persistence znode- Le znode de persistance est actif même après que le client, qui a créé ce znode particulier, est déconnecté. Par défaut, tous les znodes sont persistants, sauf indication contraire.

  • Ephemeral znode- Les znodes éphémères sont actifs jusqu'à ce que le client soit vivant. Lorsqu'un client est déconnecté de l'ensemble ZooKeeper, les znodes éphémères sont supprimés automatiquement. Pour cette raison, seuls les znodes éphémères ne sont pas autorisés à avoir d'autres enfants. Si un znode éphémère est supprimé, le nœud approprié suivant remplira sa position. Les znodes éphémères jouent un rôle important dans l'élection du leader.

  • Sequential znode- Les znodes séquentiels peuvent être persistants ou éphémères. Lorsqu'un nouveau znode est créé en tant que znode séquentiel, ZooKeeper définit le chemin du znode en attachant un numéro de séquence à 10 chiffres au nom d'origine. Par exemple, si un znode avec chemin/myapp est créé en tant que znode séquentiel, ZooKeeper changera le chemin en /myapp0000000001et définissez le numéro de séquence suivant sur 0000000002. Si deux znodes séquentiels sont créés simultanément, ZooKeeper n'utilise jamais le même numéro pour chaque znode. Les znodes séquentiels jouent un rôle important dans le verrouillage et la synchronisation.

Séances

Les sessions sont très importantes pour le fonctionnement de ZooKeeper. Les demandes dans une session sont exécutées dans l'ordre FIFO. Une fois qu'un client se connecte à un serveur, la session est établie et unsession id est attribué au client.

Le client envoie heartbeatsà un intervalle de temps particulier pour garder la session valide. Si l'ensemble ZooKeeper ne reçoit pas de pulsations d'un client pendant plus de la période (délai d'expiration de session) spécifiée au démarrage du service, il décide que le client est décédé.

Les délais d'expiration de session sont généralement représentés en millisecondes. Lorsqu'une session se termine pour une raison quelconque, les znodes éphémères créés au cours de cette session sont également supprimés.

Montres

Les montres sont un mécanisme simple permettant au client de recevoir des notifications sur les modifications apportées à l'ensemble ZooKeeper. Les clients peuvent régler des montres tout en lisant un znode particulier. Les montres envoient une notification au client enregistré pour tout changement de znode (sur lequel le client s'enregistre).

Les changements Znode sont des modifications de données associées au znode ou des changements dans les enfants du znode. Les montres ne sont déclenchées qu'une seule fois. Si un client souhaite à nouveau une notification, il doit être effectué via une autre opération de lecture. Lorsqu'une session de connexion est expirée, le client est déconnecté du serveur et les montres associées sont également supprimées.