[Collection recommandée] Torture de l'âme ! Canon à 31 coups du gardien de zoo-javaDidacticiel-php.cn

Résumé des connaissances de base de Zookeeper

[Collection recommandée] Torture de l'âme ! Canon à 31 coups du gardien de zoo

Veuillez lire le titre

Qu'est-ce que ZooKeeper ?
Que propose ZooKeeper ?
Système de fichiers Zookeeper
Comment Zookeeper s'assure-t-il que l'état des nœuds maître et esclave est synchronisé ?
Quatre types de nœuds de données Znode
Mécanisme Zookeeper Watcher - notification de changement de données
Comment l'enregistrement des clients Watcher est-il implémenté ?
Comment implémenter le traitement côté serveur de Watcher ?
Comment le client rappelle-t-il Watcher ?
Connaissez-vous le mécanisme de contrôle des autorisations ACL ?
Connaissez-vous les fonctionnalités de Chroot ?
Connaissez-vous la gestion de session
Quels sont les rôles du serveur ?
Statut de fonctionnement du serveur sous Zookeeper
Comment les données sont-elles synchronisées ?
Comment zookeeper assure-t-il la cohérence séquentielle des transactions ?
Pourquoi y a-t-il un nœud maître dans un cluster distribué ?
zk Comment gérer les temps d'arrêt des nœuds ?
La différence entre l'équilibrage de charge zookeeper et l'équilibrage de charge nginx
Quels sont les modes de déploiement de Zookeeper ?
Quel est le nombre minimum de machines requis pour un cluster ? Quelles sont les règles du cluster ? Il y a 3 serveurs dans le cluster et l'un des nœuds est en panne. Zookeeper peut-il encore être utilisé à ce moment-là ?
Le cluster prend-il en charge l'ajout dynamique de machines ?
La notification de surveillance de la surveillance de Zookeeper pour les nœuds est-elle permanente ? Pourquoi pas permanent ?
Quels sont les clients java de Zookeeper ?
Qu'est-ce que c'est potelé et comment le comparez-vous au gardien de zoo ?
Parlons de quelques commandes couramment utilisées de zookeeper.
Quelles sont les connexions et les différences entre les algorithmes ZAB et Paxos ?
Scénarios d'application typiques de Zookeeper
Quelles sont les fonctions de Zookeeper ?
Parlez-moi du mécanisme de notification de Zookeeper ?
La relation entre Zookeeper et Dubbo ?

Combien de réponses pouvez-vous donner ?

1. Qu'est-ce que ZooKeeper ?

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 :

Cohérence séquentielle
Atomicité
Vue unique
Fiabilité
Temps réel (cohérence éventuelle )

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.

2. Que propose ZooKeeper ?

Système de fichiers Zookeeper
Mécanisme de notification

3. znode ). À la différence du système de fichiers, ces nœuds peuvent définir les données associées. Dans le système de fichiers, seuls les nœuds de fichiers peuvent stocker des données mais pas les nœuds de répertoire. Bienvenue à suivre"

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 ?

Le cœur de Zookeeper est le mécanisme de diffusion atomique, qui assure la synchronisation entre les serveurs. Le protocole qui implémente ce mécanisme est appelé protocole Zab. Le protocole Zab dispose de deux modes, à savoir le mode récupération et le mode diffusion.
Mode de récupération

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.

Mode de diffusion

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.

5. Parlons des nœuds de données que possède Zookeeper

Nœud persistant-persistant

À moins d'être supprimé manuellement, le nœud existe toujours sur Zookeeper

EPHE MERAL - temporaire node

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é.

PERSISTENT_SEQUENTIAL - Nœud séquentiel persistant

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.

EPHEMERAL_SEQUENTIAL - Nœud séquentiel temporaire

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.

6. Parlons du mécanisme Zookeeper Watcher

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.

7. Comment le client enregistre l'implémentation de Watcher

(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.

8. Comment le serveur gère la mise en œuvre de Watcher

(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.

9. Comment le client rappelle le Watcher

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.

10. Connaissez-vous le mécanisme de contrôle des autorisations ACL ?

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 :

Mode d'autorisation (schéma)

(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

Objet d'autorisation

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.

Permission

(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

En configurant Chroot, un client peut être appliqué à un sous-arbre du serveur Zookeeper. Dans les scénarios où plusieurs applications partagent un Zookeeper dans le groupe, il est très utile d'obtenir une isolation mutuelle entre différentes applications.

12. Connaissez-vous la gestion de sessions ?

Principe de distribution : "Prochain délai d'expiration" (ExpirationTime) de chaque sessionFormule de calcul :

ExpirationTime_ = currentTime + sessionTimeout

ExpirationTime = (ExpirationTime_ / ExpirationInrerval + 1) *

ExpirationInterval, ExpirationInterval fait référence à la session Zookeeper intervalle de vérification du délai d'expiration, tickTime par défaut

13. Quels sont les rôles du serveur

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

14. Statut de fonctionnement du serveur sous Zookeeper

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.

15. Pouvez-vous me dire comment les données sont synchronisées ?

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 :

Extraire lastZxid (le dernier ZXID traité par le serveur Apprenant) du message ACKEPOCH envoyé lors de l'enregistrement du serveur apprenant

minCommitteeLog :

Le minimum ZXID dans la file d'attente de cache de propositions du serveur Leader commitLog maxCommitteLog :
Le ZXID maximum dans la file d'attente de cache de propositions du serveur Leader commitLog synchronisation différentielle directe (synchronisation DIFF)
Scénario : peerLastZxid est entre minCommittelLog et maxCommittelLog, revenez d'abord en arrière et puis Synchronisation différentielle (synchronisation TRUNC+DIFF)
Scénario : Lorsque le nouveau serveur Leader découvre qu'un serveur Apprenant contient un enregistrement de transaction qu'il n'a pas, il doit demander au serveur Apprenant d'effectuer une restauration de la transaction - restauration vers le Leader Le

ZXID qui existe sur le serveur et qui est le plus proche de peerLastZxid annule uniquement la synchronisation (synchronisation TRUNC)

Scénario : peerLastZxid est supérieur à maxCommittelLog

Synchronisation complète (synchronisation SNAP)

Scénario 1 : peerLastZxid est inférieur à minCommittelLog
Scénario 2 : Il n'y a pas de file d'attente de cache de proposition sur le serveur Leader et peerLastZ xid n'est pas égal à lastProcessZxid

16. Comment zookeeper assure-t-il la cohérence séquentielle des transactions ?

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.

17. Pourquoi y a-t-il un nœud maître dans un cluster distribué ?

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. .

18. Comment gérer les temps d'arrêt du nœud zk ?

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)

19. l'équilibrage de charge de zookeeper et l'équilibrage de charge de nginx

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.

20. Quels sont les modes de déploiement de Zookeeper ?

Zookeeper propose trois modes de déploiement :

Déploiement sur une seule machine : exécuté sur un cluster ;
Déploiement en cluster : exécuté sur plusieurs clusters
Déploiement de pseudo-cluster : démarrage de plusieurs clusters ; un cluster L'instance Zookeeper est en cours d'exécution.

21. Combien de machines sont nécessaires au moins pour un cluster ? Il y a 3 serveurs dans le cluster et l'un des nœuds est en panne. Zookeeper peut-il encore être utilisé à ce moment-là ?

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.

22. Le cluster prend-il en charge l'ajout dynamique de machines ?

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.

23. Les notifications de surveillance de Zookeeper pour les nœuds sont-elles permanentes ?

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.

24. Quels sont les clients Java de Zookeeper ?

Client Java : le propre zkclient de zk et le conservateur open source d'Apache.

25. Qu'est-ce qui est potelé et comment vous comparez-vous à un gardien de zoo ?

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.

26. Parlons de quelques commandes couramment utilisées de zookeeper.

Commandes communes : ls get set create delete etc.

27. Quelles sont les connexions et les différences entre les algorithmes ZAB et Paxos ?

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.

28. Scénarios d'application typiques de Zookeeper

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

29. Quelles sont les fonctions de Zookeeper ?

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é.

30. Parlez-moi du mécanisme de notification de Zookeeper ?

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.

31. Quelle est la relation entre Zookeeper et Dubbo ?

Le rôle de Zookeeper

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.

dubbo

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.

La relation entre zookeeper et dubbo :

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.