![[Collection recommandée] Torture de l'âme ! Canon à 31 coups du gardien de zoo](https://img.php.cn/upload/article/001/273/727/77277e0c45b71f73ee319bcf8a6ed2e7-0.png)
Combien de réponses pouvez-vous donner ?
ZooKeeper est un service de coordination distribué open source. Il s'agit d'un logiciel qui fournit des services de cohérence pour les applications distribuées. Les applications distribuées peuvent implémenter des tâches telles que la publication/abonnement de données, l'équilibrage de charge, le service de nommage, la coordination/notification distribuée, la gestion de cluster, l'élection du maître, les verrous distribués et les files d'attente distribuées et d'autres fonctions.
L'objectif de ZooKeeper est d'encapsuler des services clés complexes et sujets aux erreurs et de fournir aux utilisateurs des interfaces simples et faciles à utiliser ainsi qu'un système doté de performances efficaces et de fonctions stables.
Zookeeper garantit les fonctionnalités de cohérence distribuée suivantes :
La lecture du client La demande peut être traitée par n'importe quelle machine du cluster. Si la demande de lecture a un écouteur enregistré sur le nœud, l'écouteur sera également traité par la machine zookeeper connectée. Pour les demandes d'écriture, ces demandes seront envoyées à d'autres machines zookeeper en même temps et ce n'est qu'une fois le consensus atteint que la demande sera renvoyée avec succès. Par conséquent, à mesure que le nombre de machines du cluster zookeeper augmente, le débit des requêtes de lecture augmentera mais le débit des requêtes d’écriture diminuera.
La commande est une fonctionnalité très importante dans zookeeper. Toutes les mises à jour sont classées globalement. Chaque mise à jour a un horodatage unique est appelé zxid (Zookeeper Transaction Id). La demande de lecture ne sera ordonnée que par rapport à la mise à jour, c'est-à-dire que le résultat renvoyé de la demande de lecture contiendra le dernier zxid du gardien de zoo.
Chronique d'interview" pour obtenir plus d'interviewsinformations sèches. Afin de garantir un débit élevé et une faible latence, Zookeeper maintient cette structure de répertoires arborescente en mémoire. Cette fonctionnalité empêche Zookeeper de stocker de grandes quantités de données. La limite supérieure de stockage de données pour chaque nœud est de 1 Mo.
4. Comment Zookeeper assure-t-il la synchronisation des statuts des nœuds maîtres et esclaves ?
Lorsque le service démarre ou après le crash du leader, Zab entre en mode de récupération. Lorsque le leader est élu et que la plupart des serveurs terminent la synchronisation de l'état avec le leader, le mode de récupération se termine. La synchronisation des états garantit que le leader et le serveur ont le même état système.
Une fois que le leader a synchronisé son statut avec la majorité de ses abonnés, il peut commencer à diffuser des messages, c'est-à-dire qu'il entre dans l'état de diffusion. À ce moment-là, lorsqu'un serveur rejoint le service ZooKeeper, il démarre en mode de récupération, découvre le leader et synchronise son statut avec celui-ci. Lorsque la synchronisation est terminée, il participe également à la diffusion des messages. Le service ZooKeeper reste dans l'état Diffusion jusqu'à ce que le leader tombe en panne ou qu'il perde la plupart de son soutien.
À moins d'être supprimé manuellement, le nœud existe toujours sur Zookeeper
Le cycle de vie des nœuds temporaires est lié à la session client. Une fois la session client expirée (la déconnexion entre le client et zookeeper ne signifie pas nécessairement que la session expire), alors tous les nœuds temporaires créés par ce client le seront. être retiré.
Les fonctionnalités de base sont les mêmes que celles du nœud persistant, sauf que l'attribut de séquence est ajouté. Un nombre entier auto-croissant maintenu par le nœud parent sera ajouté au nœud parent. nom du nœud.
Les fonctionnalités de base sont les mêmes que celles des nœuds temporaires, avec l'ajout d'un attribut de séquence. Un nombre entier auto-croissant maintenu par le nœud parent sera ajouté au nom du nœud.
Zookeeper permet au client d'enregistrer un Watcher avec un Znode sur le serveur Lorsque certains événements spécifiés sur le serveur déclenchent ce Watcher, le serveur enverra un message. au client spécifié. Une notification d'événement est utilisée pour implémenter la fonction de notification distribuée, puis le client apporte des modifications commerciales en fonction de l'état de notification Watcher et du type d'événement. Bienvenue à suivre "Interview Column" pour obtenir plus d'informations sur les entretiens.
Mécanisme de fonctionnement :
(1) Le client enregistre l'observateur
(2) L'observateur des processus du serveur
(3) Le client rappelle l'observateur
Résumé des fonctionnalités de l'observateur :
(1) Unique
Peu importe. un service Qu'il s'agisse du client ou du client, une fois qu'un Watcher est déclenché, Zookeeper le supprimera du stockage correspondant. Cette conception réduit efficacement la pression sur le serveur, sinon, pour les nœuds mis à jour très fréquemment, le serveur enverra en permanence des notifications d'événements au client, ce qui exerce une forte pression sur le réseau et le serveur.
(2) Exécution série du client
Le processus de rappel du client Watcher est un processus de synchronisation série.
(3) Léger
3.1. La notification Watcher est très simple. Elle indiquera uniquement au client qu'un événement s'est produit, mais n'expliquera pas le contenu spécifique de l'événement.
3.2. Lorsque le client enregistre un Watcher auprès du serveur, il ne transmet pas la véritable entité objet Watcher du client au serveur. Elle est uniquement marquée avec un attribut de type booléen dans la requête du client.
(4) l'événement watcher est envoyé de manière asynchrone
L'événement de notification watcher est envoyé de manière asynchrone du serveur au client. Cela crée un problème. Différents clients et serveurs communiquent via des sockets, ce qui peut être causé par des retards du réseau ou d'autres facteurs. Le client surveille les événements aux moments indisponibles car Zookeeper lui-même fournit une garantie d'ordre, c'est-à-dire que ce n'est qu'après que le client a surveillé l'événement qu'il percevra les changements dans le znode qu'il surveille. Par conséquent, lorsque nous utilisons Zookeeper, nous ne pouvons pas nous attendre à pouvoir surveiller chaque changement du nœud. Zookeeper ne peut garantir qu'une cohérence éventuelle, mais ne peut pas garantir une cohérence forte.
(5) Enregistrez l'observateur getData, existe, getChildren
(6) Déclenchez l'observateur créer, supprimer, setData
(7) Lorsqu'un client se connecte à un nouveau serveur, la surveillance sera déclenchée par tout événement de session. Lorsque la connexion à un serveur est perdue, les montres ne peuvent pas être reçues. Lorsque le client se reconnectera, toutes les montres précédemment enregistrées seront réenregistrées si nécessaire. Habituellement, cela est complètement transparent. Il n'y a qu'un seul cas particulier où une surveillance peut être perdue : pour une surveillance existante sur un znode non créé, si elle a été créée alors que le client était déconnecté puis supprimée avant que le client ne se connecte, cet événement de surveillance peut être perdu.
(1) Appelez les trois API getData()/getChildren()/exist() et transmettez l'objet Watcher
(2) Marquez la requête request, encapsulez le Watcher dans WatchRegistration
(3) Encapsulez-le dans un objet Packet, envoyez la requête au serveur
(4) Après avoir reçu la réponse du serveur, enregistrez le Watcher dans ZKWatcherManager pour la gestion
(5) La demande revient et l'inscription est complétée.
(1) Le serveur reçoit le Watcher et le stocke
Reçoit la demande du client, traite la demande pour déterminer si le Watcher doit être enregistré et si nécessaire, le nœud de données Le chemin du nœud et ServerCnxn (ServerCnxn représente une connexion entre le client et le serveur, implémente l'interface de processus de Watcher et peut être considéré comme un objet Watcher à ce moment) sont stockés dans WatchTable et watch2Paths de WatcherManager .
(2) Déclencheur Watcher
Prenez le serveur recevant la demande de transaction setData() pour déclencher l'événement NodeDataChanged à titre d'exemple :
2.1 Encapsulation WatchedEvent
Encapsulez l'état de notification (SyncConnected), le type d'événement (NodeDataChanged) et le nœud chemin dans un objet WatchedEvent
2.2 Requête Watcher
Trouver Watcher à partir de WatchTable en fonction du chemin du nœud
2.3 Non trouvé ; indiquant qu'aucun client n'a enregistré Watcher sur ce nœud de données
2.4 Rechercher ; extraire et supprimer le Watcher correspondant de WatchTable et Watch2Paths (on peut voir à partir d'ici que le Watcher est ponctuel côté serveur et devient invalide après avoir été déclenché une fois)
(3) Appeler la méthode de processus pour déclencher le Watcher
Voici le processus L'objectif principal est d'envoyer des notifications d'événements Watcher via la connexion TCP correspondant à ServerCnxn.
Le thread SendThread client reçoit la notification d'événement et le thread EventThread rappelle le Watcher.
Le mécanisme Watcher du client est également unique. Une fois déclenché, le Watcher deviendra invalide.
UGO (Utilisateur/Groupe/Autres)
est actuellement utilisé dans les systèmes de fichiers Linux/Unix et constitue également la méthode de contrôle des autorisations la plus largement utilisée. Il s’agit d’un mode de contrôle des autorisations du système de fichiers à gros grain. La liste de contrôle d'accès
ACL (Access Control List)
comprend trois aspects :
(1) IP : contrôle des autorisations à partir de la granularité de l'adresse IP
(2) Digest : le plus souvent utilisées, les autorisations sont configurées à l'aide d'identifiants d'autorisation similaires à nom d'utilisateur: mot de passe, ce qui est pratique pour distinguer les différentes applications de contrôle des autorisations
(3) Monde : la méthode de contrôle des autorisations la plus ouverte, un mode résumé spécial avec une seule autorisation Identification "monde : n'importe qui"
(4) Super : Super utilisateur
L'objet d'autorisation fait référence à l'utilisateur ou à une entité désignée bénéficiant d'une autorisation, comme une adresse IP ou une lumière de machine.
(1) CREATE : autorisation de création de nœud de données, permettant aux objets autorisés de créer des nœuds enfants sous ce Znode
(2) DELETE : autorisation de suppression de nœud enfant, permettant aux objets autorisés de supprimer les enfants de ces données node Node
(3) READ : L'autorisation de lecture du nœud de données, permettant à l'objet autorisé d'accéder au nœud de données et de lire son contenu de données ou sa liste de sous-nœuds, etc.
(4) WRITE : La mise à jour du nœud de données autorisation, permettant à l'objet autorisé d'effectuer des opérations de mise à jour. feature
12. Connaissez-vous la gestion de sessions ?
Leader
(1) Le seul planificateur et processeur des demandes de transactions, assurant l'ordre de traitement des transactions du cluster
(2) Le planificateur de chaque service au sein du cluster
Follower
(1) Traiter les demandes de non-transaction des clients et transmettre les demandes de transaction au serveur Leader
(2) Participer au vote des propositions de demandes de transaction
(3) Participer au vote de l'élection Leader
Observateur
(1) Version 3.0 Un rôle de serveur sera introduit ultérieurement pour améliorer les capacités de traitement non transactionnel du cluster sans affecter les capacités de traitement transactionnel du cluster
(2) Traiter les demandes non transactionnelles du client et transmettre les demandes de transaction au Serveur leader
(3) Ne participez à aucune forme de vote
Le serveur a quatre statuts, à savoir LOOKING, SUIVI, LEADING et OBSERVING.
(1) EN RECHERCHE : En recherche du statut de Leader. Lorsque le serveur est dans cet état, il pensera qu'il n'y a pas de leader dans le cluster actuel, il doit donc entrer dans l'état d'élection du leader.
(2) SUIVANT : statut de follower. Indique que le rôle serveur actuel est Follower.
(3) LEADING : Statut de leader. Indique que le rôle serveur actuel est Leader.
(4) OBSERVATION : Statut d'observateur. Indique que le rôle serveur actuel est Observer.
Une fois que l'ensemble du cluster a terminé l'élection du leader, l'apprenant (le nom collectif du suiveur et de l'observateur) se réinscrit sur le serveur Leader. Une fois que le serveur Learner a terminé son enregistrement auprès du serveur Leader, il entre dans la phase de synchronisation des données.
Processus de synchronisation des données : (tous effectués par messagerie)
L'apprenant s'inscrit auprès de Learner
Synchronisation des données
Confirmation de la synchronisation
La synchronisation des données de Zookeeper est généralement divisée en quatre catégories :
(1) Synchronisation différentielle directe (synchronisation DIFF)
(2) Rollback d'abord puis synchronisation différentielle (synchronisation TRUNC+DIFF)
(3) Synchronisation rollback uniquement (synchronisation TRUNC)
(4) Synchronisation complète (synchronisation SNAP)
En cours Avant la synchronisation des données, le Leader Le serveur terminera l'initialisation de la synchronisation des données :
peerLastZxid :
minCommitteeLog :
ZXID qui existe sur le serveur et qui est le plus proche de peerLastZxid annule uniquement la synchronisation (synchronisation TRUNC)
Synchronisation complète (synchronisation SNAP)
zookeeper utilise un identifiant de transaction incrémenté globalement pour l'identifier. Toutes les propositions sont ajoutées avec zxid lorsqu'elles sont proposées. zxid est en fait un nombre de 64 bits, et les 32 bits supérieurs sont l'époque (période) ; ; nouvelle ère) est utilisé pour identifier le cycle leader Si un nouveau leader est généré, l'époque augmentera automatiquement et les 32 bits inférieurs sont utilisés pour incrémenter le décompte. Lorsqu'une nouvelle proposition est générée, elle émettra d'abord une demande d'exécution de transaction aux autres serveurs sur la base du processus en deux étapes de la base de données. Si plus de la moitié des machines peuvent l'exécuter et réussir, alors l'exécution commencera.
Dans un environnement distribué, certaines logiques métier ne doivent être exécutées que par une certaine machine du cluster, et d'autres machines peuvent partager les résultats, ce qui peut réduire considérablement les calculs répétés et améliorer les performances, l'élection du leader est donc nécessaire. .
Zookeeper lui-même est également un cluster, et il est recommandé de configurer pas moins de 3 serveurs. Zookeeper lui-même doit également garantir que lorsqu'un nœud tombe en panne, les autres nœuds continueront à fournir des services.
Si un Follower tombe en panne, il y a encore 2 serveurs fournissant l'accès. Parce que les données sur Zookeeper ont plusieurs copies, les données ne seront pas perdues.
Si un Leader tombe en panne, Zookeeper en élira un nouveau.
Le mécanisme du cluster ZK est que tant que plus de la moitié des nœuds sont normaux, le cluster peut fournir des services normalement. Le cluster échouera uniquement lorsqu'il y aura trop de nœuds ZK et que seulement la moitié ou moins de la moitié des nœuds pourront fonctionner.
Alors
Un cluster de 3 nœuds peut faire échouer 1 nœud (le leader peut obtenir 2 voix>1,5)
Un cluster de 2 nœuds ne peut faire échouer aucun nœud (le leader peut obtenir 1 voix<=1)
l'équilibrage de charge de zk peut être ajusté, nginx ne peut ajuster que les poids, les autres éléments qui doivent être contrôlables doivent écrire leurs propres plug-ins mais le débit de nginx est supérieur à ; zk est beaucoup plus grand. Il faut dire que vous choisissez la méthode à utiliser en fonction du métier.
Zookeeper propose trois modes de déploiement :
La règle du cluster est 2N+1 unités, N>0, soit 3 unités. Vous pouvez continuer à utiliser les serveurs impairs tant que pas plus de la moitié des serveurs ne sont pas en panne.
En fait, c'est une expansion horizontale. Zookeeper n'est pas très bon dans cet aspect. Deux manières :
Tout redémarrer : fermez tous les services Zookeeper, modifiez la configuration et démarrez-les. N'affecte pas les sessions client précédentes.
Redémarrer une par une : Sous le principe que plus de la moitié des machines sont vivantes et disponibles, le redémarrage d'une machine n'affectera pas l'ensemble des services externes du cluster. C'est la méthode la plus couramment utilisée.
La version 3.5 commence à prendre en charge l'expansion dynamique.
Non. Déclaration officielle : un événement Watch est un déclencheur unique Lorsque les données pour lesquelles la Watch est définie changent, le serveur envoie la modification au client pour lequel la Watch est définie pour le notifier.
Pourquoi n'est-ce pas permanent ? Par exemple, si le serveur change fréquemment et que les clients de surveillance le sont dans de nombreux cas, tous les clients doivent être informés de chaque changement, ce qui met beaucoup de pression sur le réseau et le serveur.
Généralement, le client exécute getData("/node A", true). Si le nœud A est modifié ou supprimé, le client obtiendra son événement de surveillance, mais le nœud A changera à nouveau et le client si l'événement de surveillance ne l'est pas. défini, il ne sera plus envoyé au client.
Dans les applications pratiques, dans de nombreux cas, notre client n'a pas besoin de connaître chaque changement sur le serveur, j'ai seulement besoin des dernières données.
Client Java : le propre zkclient de zk et le conservateur open source d'Apache.
chubby vient de Google, implémente entièrement l'algorithme paxos et n'est pas open source. Zookeeper est une implémentation open source de Chubby, utilisant le protocole zab et une variante de l'algorithme paxos.
Commandes communes : ls get set create delete etc.
Mêmes points :
(1) Les deux ont un rôle similaire au processus Leader, qui est chargé de coordonner le fonctionnement de plusieurs processus Follower
(2) Le processus Leader attendra plus de la moitié du temps. Les abonnés doivent prendre une décision Ce n'est qu'après un retour correct qu'une proposition sera soumise
(3) Dans le protocole ZAB, chaque proposition contient une valeur d'époque pour représenter le cycle actuel du leader. Le nom en Paxos est Ballot
Différences :
ZAB. Il est utilisé pour créer un système de sauvegarde et de maîtrise des données distribuées hautement disponible (Zookeeper), et Paxos est utilisé pour créer un système de machine à états à cohérence distribuée.
Zookeeper est un cadre de gestion et de coordination de données distribuées de modèle de publication/abonnement typique que les développeurs peuvent utiliser pour publier et s'abonner à des données distribuées.
En utilisant de manière croisée les nœuds de données riches de Zookeeper et en coopérant avec le mécanisme de notification d'événements Watcher, il est très pratique de créer une série de fonctions de base impliquées dans les applications distribuées, telles que :
(1) Publication de données/ abonnement
(2) Équilibrage de charge
(3) Service de nommage
(4) Coordination/notification distribuée
(5) Gestion de cluster
(6) Élection du maître
(7) Verrouillage distribué
(8) File d'attente distribuée
Gestion du cluster : surveillez l'état de survie du nœud, les requêtes en cours d'exécution, etc. ;
Élection du nœud maître : une fois que le nœud maître a raccroché, vous pouvez démarrer un nouveau tour d'élection du leader à partir du nœud de sauvegarde. L'élection du nœud maître concerne le processus, l'utilisation de Zookeeper peut vous aider à terminer ce processus.
Verrouillage distribué : Zookeeper fournit deux types de verrous : les verrous exclusifs et les verrous partagés. Un verrou exclusif signifie qu'un seul thread peut utiliser la ressource à la fois. Un verrou partagé signifie que le verrou de lecture est partagé et que la lecture et l'écriture s'excluent mutuellement, c'est-à-dire que plusieurs threads peuvent lire la même ressource en même temps. un verrou en écriture doit être utilisé, un seul thread peut l'utiliser. Zookeeper peut contrôler les verrous distribués.
Service de nommage : dans un système distribué, en utilisant le service de nommage, l'application client peut obtenir l'adresse, le fournisseur et d'autres informations de la ressource ou du service en fonction du nom spécifié.
Le client créera un événement d'observateur pour un certain znode. Lorsque le znode change, ces clients recevront des notifications zk, puis le client pourra apporter des modifications commerciales en fonction des modifications du znode.
zookeeper est utilisé pour enregistrer les services et effectuer l'équilibrage de charge. Quel service est fourni par quelle machine doit être connu de l'appelant. En termes simples, c'est la correspondance entre l'IP. l'adresse et le nom du service. Bien entendu, cette correspondance peut également être implémentée dans le code professionnel de l'appelant via un codage en dur. Cependant, si la machine qui fournit le service raccroche, l'appelant n'a aucun moyen de savoir si le code n'est pas modifié, il continuera à demander. la machine morte pour fournir des services. Zookeeper peut détecter la machine bloquée via le mécanisme de battement de cœur et supprimer la relation correspondante entre l'adresse IP et le service de la machine bloquée de la liste. Quant à la prise en charge d'une concurrence élevée, cela signifie simplement une expansion horizontale, augmentant la puissance de calcul en ajoutant des machines sans modifier le code. En ajoutant de nouvelles machines pour enregistrer les services auprès de ZooKeeper, plus il y a de fournisseurs de services, plus ils peuvent servir de clients.
est un outil de gestion de la couche intermédiaire. Entre la couche métier et l'entrepôt de données, il existe de nombreux fournisseurs d'accès aux services et de services qui doivent être planifiés. Dubbo fournit un cadre pour résoudre ce problème.
Notez que le dubbo ici n'est qu'un cadre. Ce que vous mettez sur l'étagère dépend entièrement de vous, tout comme un squelette de voiture, vous devez l'adapter à votre moteur de roue. Pour compléter la planification dans ce cadre, il doit y avoir un centre d'enregistrement distribué pour stocker les métadonnées de tous les services. Vous pouvez utiliser zk ou autres, mais tout le monde utilise zk.
Dubbo résume le centre d'enregistrement. Il peut connecter en externe différents supports de stockage pour fournir des services au centre d'enregistrement, notamment ZooKeeper, Memcached, Redis, etc.
La présentation de ZooKeeper comme support de stockage présente également les fonctionnalités de ZooKeeper. Le premier est l'équilibrage de charge. La capacité de charge d'un seul centre d'enregistrement est limitée. Lorsque le trafic atteint un certain niveau, il doit être détourné dans le but de détourner le trafic. ; la synchronisation des ressources, l'équilibrage de charge à lui seul ne suffisent pas, les données et les ressources entre les nœuds doivent être synchronisées, et les clusters ZooKeeper disposent naturellement d'un tel service de nommage, utilisant une structure arborescente pour maintenir une liste d'adresses de service globale ; fournisseurs de services Lors du démarrage, écrivez votre propre adresse URL dans le répertoire /dubbo/${serviceName}/providers du nœud spécifié sur ZooKeeper. Cette opération termine la publication du service. Les autres fonctionnalités incluent l'élection du mât, les verrous distribués, etc.
![[Collection recommandée] Torture de l'âme ! Canon à 31 coups du gardien de zoo](https://img.php.cn/upload/article/001/273/727/d1c2498c21060c678324dd90c83125e4-1.jpg)
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!
Quelle est la différence entre Dubbo et Zookeeper
Utilisation composée
Comment modifier element.style
Comment résoudre 400mauvaises requêtes
Bitcoin réduit de moitié
Introduction aux types d'interfaces de disque dur
Vérifier l'espace disque sous Linux
Trois frameworks majeurs pour le développement Android
![[Web front-end] Démarrage rapide de Node.js](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
