Modèle de données ZooKeeper

ZooKeeper a un espace de noms hiérarchique, similaire à un système de fichiers distribué. La seule différence entre eux est que chaque nœud de l'espace de noms peut avoir des associations de données comme nœuds enfants. C'est comme avoir un système de fichiers qui permet aux fichiers d'être également des répertoires de fichiers. Les chemins de nœuds sont généralement exprimés sous forme de chemins absolus canoniques séparés par des barres obliques. Ils n'ont pas de chemins relatifs. Tous les caractères Unicode inclus dans le chemin doivent respecter les contraintes suivantes :
1) Les caractères nuls ne peuvent pas être utilisés comme noms de chemin ;
2) Les chaînes suivantes ne peuvent pas être utilisées comme, ce qui est supérieur à leur affichage peu convivial, ou facile à semer la confusion (u0001 - u001F et u007F - u009F)
3) Les chaînes suivantes ne sont pas autorisées. (ud800 - uF8FF, uFFF0 - uFFFF)
4) Le caractère "." peut être utilisé dans le nom, mais "." et ".." ne peuvent pas exister seuls pour représenter le chemin d'un nœud, car ZooKeeper n'utilise pas de chemins relatifs. Les exemples suivants ne sont pas valides "/a/b/./c" ou "/a/b/../c"
5) Le mot-clé "zookeeper" est réservé

ZNodes

Chaque nœud de l'arborescence ZooKeeper peut être appelé un znode. Les Znodes maintiennent une structure de données d'état qui contient les numéros de version des modifications de données, les modifications d'ACL et les horodatages. Le numéro de version ainsi qu'un horodatage permettent à ZooKeeper d'effectuer le remplacement du cache et de coordonner les mises à jour. Chaque fois que les données d'un znode changent, le numéro de version sera incrémenté. Par exemple, chaque fois qu'un client reçoit des données, il reçoit également une version de ces données. Dans le même temps, lorsque le client effectue une opération de mise à jour ou de suppression, il doit fournir la version des données du nœud znode modifié. Si le numéro de version fourni par le znode ne correspond pas au numéro de version réel des données actuelles, la mise à jour échouera.

Remarque :

Dans un projet d'application distribuée, le nœud de mot peut être considéré comme un hôte unique, un serveur, un membre de l'ensemble et un processeur client et ainsi de suite. Dans la documentation ZooKeeper, les znodes sont considérés comme des nœuds de données. Les serveurs sont considérés comme les hôtes qui composent le service ZooKeeper. Les pairs du quorum sont considérés comme des serveurs formant un tout et les clients sont considérés comme un hôte ou un processus utilisant le service ZooKeeper.

Les Znodes sont les principales entités auxquelles accèdent les programmeurs. Ils ont de nombreuses fonctionnalités intéressantes à connaître :

Montres (auditeur)

Les clients peuvent écouter sur znodes. Les modifications apportées au znode déclencheront cet écouteur, puis l'effaceront. Lorsqu'un écouteur est déclenché, ZooKeeper envoie une notification au client.

Accès aux données (accès aux données)

Les données stockées dans le znode dans l'espace de noms sont lues ou écrites de manière atomique. Les opérations de lecture liront tous les octets de données associés au znode et les opérations d'écriture remplaceront toutes les données. Chaque nœud dispose d'une liste d'accès aux données de liste de contrôle d'accès (ACL) qui limite qui peut faire quoi.

ZooKeeper n'est pas conçu pour être utilisé comme base de données ou comme stockage d'objets volumineux, il est plutôt utilisé pour gérer et coordonner des données. La forme source des données peut être des informations de configuration, des informations d'état, des informations de région, etc. Une propriété commune aux différentes formes de données de coordination est qu’elles sont relativement petites, de l’ordre de 3 Ko d’octets. Le client et le serveur ZooKeeper effectuent tous deux des contrôles d'intégrité pour garantir que les znodes contiennent moins de 1 million de données, mais les données peuvent être beaucoup plus petites que cette moyenne. Opérer sur des données relativement volumineuses entraînera une longue durée d'opération, affectant ainsi le retard des autres opérations, car ce temps supplémentaire nécessite une migration des données via le réseau ou le support de stockage. Si le stockage de Big Data est nécessaire, la manière habituelle de gérer ces données est de les conserver dans un grand système de stockage, tel que NFS ou HDFS, puis de stocker un pointeur vers l'emplacement de stockage des données dans ZooKeeper.

Nœuds éphémères (nœuds temporaires)

ZooKeeper a le concept de nœuds éphémères. Tant que la session qui a créé les nœuds est active, ces nœuds existent toujours. Lorsque la session est fermée, ces nœuds seront également supprimés. En raison de ce comportement, les nœuds temporaires ne sont pas autorisés à avoir des nœuds enfants.

Nœuds de séquence -- Dénomination unique (Nœuds de séquence - Dénomination unique)

Lors de la création d'un nœud, vous pouvez demander à ZooKeeper d'ajouter un compteur croissant de façon monotone à la fin du chemin. Ce compteur est unique à ce nœud parent. Le format du compteur est %010d (décimal complété par des zéros), formaté pour un tri simple. Par exemple "0000000001". Consultez Queue Recipe pour un exemple utilisant cette fonctionnalité. Remarque : Le compteur utilisé pour stocker le numéro de séquence suivant est un entier signé géré par le nœud parent. Ce compteur débordera lorsqu'il sera incrémenté au-delà de 2147483647 (le résultat doit être "-2147483647").

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!