Partage de technologie

한어Русский языкEnglishFrançaisIndonesianSanskrit日本語DeutschPortuguêsΕλληνικάespañolItalianoSuomalainenLatina

1. Contrôleur Courtier

Il existe un Controller Broker dans le cluster Kafka, qui est responsable de la gestion et de la coordination des métadonnées.

Kafka utilise Zookeeper comme outil de stockage et de gestion des métadonnées du cluster. Zookeeper enregistre les informations d'état du cluster, y compris toutes les informations sur le sujet, la partition, le leader et la réplique, etc.

Lorsque l'état du cluster change, Controller Broker écrira les informations de modification dans Zookeeper.

Lorsque le Controller Broker actuel tombe en panne, d'autres courtiers du cluster Kafka détecteront cette situation et procéderont à des élections via Zookeeper.

Une fois qu'un courtier a été élu avec succès en tant que nouveau courtier contrôleur, il lira les dernières métadonnées du cluster de Zookeeper.

Mécanisme de garantie

• Métadonnées persistantes: Zookeeper stocke de manière persistante les métadonnées du cluster, garantissant que les dernières informations d'état peuvent être obtenues à tout moment.
• mécanisme de battement de coeur: La connexion entre Broker et Zookeeper est maintenue via le mécanisme de battement de cœur pour détecter rapidement les pannes de Controller Broker.
• mécanisme électoral: Grâce au mécanisme d'élection de Zookeeper, un nouveau Controller Broker peut être rapidement élu et les métadonnées peuvent être synchronisées depuis Zookeeper.

2. Architecture des composants

1. Gestionnaire de journaux

LogManagerPrincipalement responsable de la gestion du stockage et de la récupération des logs Kafka (log).

Par exemple : le producteur envoie le message au Leader Broker1 de Partition0.LogManagerÉcrivez le message dans le fichier journal de Partition0 sur Broker1.

2. Gestionnaire de réplication

ReplicationManagerPrincipalement responsable de la gestion de la réplication et de la synchronisation des données de partition.

La synchronisation entre le Leader et le Follower de chaque partition s'effectue indépendamment. Autrement dit, chaque partition possède son propre processus de synchronisation et ne dépend pas des autres partitions.

Bien que le processus de synchronisation de chaque partition soit indépendant, chaque courtier démarrera les threads de réplication correspondants pour chaque partition qu'il gère (qu'elle soit leader ou suiveuse), et ces threads sont responsables de la gestion des tâches de synchronisation spécifiques.

Par exemple:ReplicationManagerEnvoyez les messages nouvellement écrits sur Broker1 vers Follower Broker2 et Broker3 de Partition0.ReplicationManagerLes demandes de réplication reçues de Broker1 sont traitées sur Broker2 et Broker3, en écrivant des messages dans leurs fichiers journaux respectifs.

3. Serveur de sockets

SocketServer Il s'agit d'un composant de Kafka Broker et est responsable de la gestion des connexions réseau et des opérations d'E/S. Il est chargé d'accepter les demandes de connexion des clients et des autres courtiers et d'attribuer un thread à chaque connexion pour le traitement.

4. Serveur réseau

NetworkServer Il constitue un élément essentiel du cadre de communication réseau de Kafka et est responsable de la gestion et de la planification des requêtes réseau. Il utilise NIO (E/S non bloquantes) pour gérer les connexions réseau hautement concurrentes.

5. ZKClient

Composant qui communique avec Zookeeper.