Apache Kafka - WorkFlow

À partir de maintenant, nous avons discuté des concepts de base de Kafka. Jetons maintenant un peu de lumière sur le flux de travail de Kafka.

Kafka est simplement une collection de sujets divisés en une ou plusieurs partitions. Une partition Kafka est une séquence de messages ordonnée linéairement, où chaque message est identifié par son index (appelé offset). Toutes les données d'un cluster Kafka sont l'union disjointe de partitions. Les messages entrants sont écrits à la fin d'une partition et les messages sont lus séquentiellement par les consommateurs. La durabilité est assurée par la réplication des messages vers différents courtiers.

Kafka fournit à la fois un système de messagerie basé sur les pubs et les files d'attente de manière rapide, fiable, persistante, avec tolérance aux pannes et sans temps d'arrêt. Dans les deux cas, les producteurs envoient simplement le message à un sujet et le consommateur peut choisir n'importe quel type de système de messagerie en fonction de ses besoins. Suivons les étapes de la section suivante pour comprendre comment le consommateur peut choisir le système de messagerie de son choix.

Flux de travail de la messagerie Pub-Sub

Voici le flux de travail par étapes de la messagerie Pub-Sub -

  • Les producteurs envoient un message sur un sujet à intervalles réguliers.

  • Le courtier Kafka stocke tous les messages dans les partitions configurées pour ce sujet particulier. Cela garantit que les messages sont également partagés entre les partitions. Si le producteur envoie deux messages et qu'il y a deux partitions, Kafka stockera un message dans la première partition et le deuxième message dans la deuxième partition.

  • Le consommateur s'abonne à un sujet spécifique.

  • Une fois que le consommateur s'est abonné à un sujet, Kafka fournira le décalage actuel du sujet au consommateur et enregistrera également le décalage dans l'ensemble Zookeeper.

  • Le consommateur demandera le Kafka dans un intervalle régulier (comme 100 ms) pour les nouveaux messages.

  • Une fois que Kafka reçoit les messages des producteurs, il transmet ces messages aux consommateurs.

  • Le consommateur recevra le message et le traitera.

  • Une fois les messages traités, le consommateur enverra un accusé de réception au courtier Kafka.

  • Une fois que Kafka reçoit un accusé de réception, il modifie le décalage avec la nouvelle valeur et la met à jour dans le Zookeeper. Étant donné que les décalages sont conservés dans le gardien de zoo, le consommateur peut lire correctement le message suivant, même pendant les outrages du serveur.

  • Ce flux ci-dessus se répétera jusqu'à ce que le consommateur arrête la demande.

  • Le consommateur a la possibilité de revenir en arrière / passer au décalage souhaité d'un sujet à tout moment et de lire tous les messages suivants.

Flux de travail de la messagerie de file d'attente / groupe de consommateurs

Dans un système de messagerie de file d'attente au lieu d'un seul consommateur, un groupe de consommateurs ayant le même ID de groupe s'abonnera à une rubrique. En termes simples, les consommateurs qui s'abonnent à un sujet avec le même ID de groupe sont considérés comme un seul groupe et les messages sont partagés entre eux. Laissez-nous vérifier le flux de travail réel de ce système.

  • Les producteurs envoient un message à un sujet à intervalles réguliers.

  • Kafka stocke tous les messages dans les partitions configurées pour cette rubrique particulière, similaire au scénario précédent.

  • Un seul consommateur s'abonne à un sujet spécifique, supposons que le sujet 01 avec l' ID de groupe est le groupe 1 .

  • Kafka interagit avec le consommateur de la même manière que Pub-Sub Messaging jusqu'à ce que le nouveau consommateur souscrive au même sujet, Topic-01 avec le même ID de groupe que Group-1 .

  • Une fois le nouveau consommateur arrivé, Kafka bascule son fonctionnement en mode partage et partage les données entre les deux consommateurs. Ce partage se poursuivra jusqu'à ce que le nombre de consommateurs atteigne le nombre de partitions configurées pour ce sujet particulier.

  • Une fois que le nombre de consommateurs dépasse le nombre de partitions, le nouveau consommateur ne recevra plus de message jusqu'à ce que l'un des consommateurs existants se désabonne. Ce scénario se produit parce que chaque consommateur de Kafka se verra attribuer au moins une partition et une fois que toutes les partitions seront attribuées aux consommateurs existants, les nouveaux consommateurs devront attendre.

  • Cette fonctionnalité est également appelée groupe de consommateurs . De la même manière, Kafka fournira le meilleur des deux systèmes d'une manière très simple et efficace.

Rôle de ZooKeeper

Une dépendance critique d'Apache Kafka est Apache Zookeeper, qui est un service de configuration et de synchronisation distribué. Zookeeper sert d'interface de coordination entre les courtiers Kafka et les consommateurs. Les serveurs Kafka partagent des informations via un cluster Zookeeper. Kafka stocke les métadonnées de base dans Zookeeper, telles que des informations sur les sujets, les courtiers, les décalages des consommateurs (lecteurs de file d'attente), etc.

Étant donné que toutes les informations critiques sont stockées dans le Zookeeper et qu'il réplique normalement ces données dans son ensemble, l'échec du courtier Kafka / Zookeeper n'affecte pas l'état du cluster Kafka. Kafka restaurera l'état, une fois que le gardien de zoo redémarrera. Cela ne donne aucun temps d'arrêt pour Kafka. L'élection du chef entre le courtier Kafka se fait également en utilisant Zookeeper en cas de défaillance du chef.

Pour en savoir plus sur Zookeeper, s'il vous plaît se référer Zookeeper

Continuons plus loin sur l'installation de Java, ZooKeeper et Kafka sur votre machine dans le chapitre suivant.