Présentation de Kafka Consumer Group
Le groupe de consommateurs Kafka est essentiellement un certain nombre de consommateurs Kafka qui peuvent lire des données en parallèle à partir d'un sujet Kafka. Un groupe de consommateurs Kafka a les propriétés suivantes:
- Tous les consommateurs d'un groupe ont le même group.id.
- Chaque partition de la rubrique est lue par un seul consommateur.
- Le nombre maximal de consommateurs est égal au nombre de partitions dans la rubrique. S'il y a plus de consommateurs que de partitions, certains des consommateurs resteront inactifs.
- Un consommateur peut lire à partir de plusieurs partitions.
Importance de Kafka Consumer Group
Pour une organisation de vente au détail, il y aura un grand nombre de producteurs générant des données à un rythme énorme. Maintenant, pour lire un grand volume de données, nous avons besoin de plusieurs consommateurs fonctionnant en parallèle. C'est relativement plus facile du côté producteur où chaque producteur génère des données indépendamment des autres. Mais, du côté des consommateurs, si plusieurs consommateurs lisent le même sujet, il y a de fortes chances que chaque message soit lu plusieurs fois. Kafka résout ce problème en utilisant Consumer Group. Dans tous les cas, un seul consommateur est autorisé à lire les données d'une partition.
Cloisons de Kafka Consumer Group
Supposons que nous ayons un sujet Kafka et qu'il y ait 4 partitions. Ensuite, nous pouvons avoir les scénarios suivants:
1. Nombre de consommateurs = nombre de partitions
Dans ce cas, chaque consommateur lira les données de chaque partition et c'est le cas idéal.
2. Nombre de consommateurs> Nombre de partitions
Dans ce cas, un consommateur restera inactif et entraînera une mauvaise utilisation de la ressource.
3. Nombre de consommateurs <Nombre de partitions
Dans ce cas, l'un des consommateurs lira les données de plusieurs partitions.
4. Nombre de groupes de consommateurs> 1
Dans ce cas, le sujet est souscrit par plusieurs groupes de consommateurs qui répondent à deux applications différentes. Les deux applications peuvent s'exécuter indépendamment l'une de l'autre.
Avantages de Kafka Consumer Group
Consumer Group ajoute les avantages suivants:
- Évolutivité: un certain nombre de consommateurs qui lisent des données en parallèle augmente définitivement le taux de consommation de données et rend le système capable de lire un volume élevé de données.
- Tolérance aux pannes: supposons que nous n'ayons qu'un seul consommateur (pour la lecture d'un volume de données moins élevé), que se passerait-il si le consommateur échoue pour une raison quelconque? L'ensemble du pipeline va se casser.
- Équilibrage de charge: Kafka partage les partitions équitablement pour chaque consommateur, ce qui rend le processus de consommation de données fluide et efficace.
- Rééquilibrage: Si un nouveau consommateur est ajouté ou qu'un existant s'arrête, Kafka rééquilibre la charge sur les consommateurs disponibles.
Comment Kafka jette un pont entre les deux modèles?
Voyons d'abord les deux modèles de messagerie.
1. Files d'attente de messages
Dans ce modèle, un flux de messages est envoyé d'un producteur à un seul consommateur. Ainsi, chaque message est en lecture seule une fois et une fois qu'un consommateur tire un message, le message est effacé de la file d'attente. Un exemple typique peut être l'émission d'un chèque de paie où chaque chèque de paie ne doit être émis qu'une seule fois. De plus, ce modèle ne garantit pas que les messages seront livrés dans l'ordre. L'évolutivité du traitement des messages est limitée à un seul domaine.
2. Messagerie de publication-abonnement
Dans ce modèle, les messages publiés par un producteur peuvent être abonnés par plusieurs consommateurs. Le producteur et le consommateur sont découplés dans une large mesure. Ce modèle garantit que chaque consommateur recevra des messages dans une rubrique dans l'ordre exact généré par le producteur. Un exemple typique peut être une télévision parabolique qui publie différentes chaînes comme la musique, les films, les sports, etc., et les consommateurs peuvent s'abonner à plusieurs chaînes. Comme il existe plusieurs abonnés à un sujet, la mise à l'échelle du traitement des flux est un défi.
Kafka est si populaire car bien qu'il soit basé sur le modèle de publication-abonnement, il présente les avantages d'un système de file d'attente de messagerie. Comme indiqué précédemment, si nous avons un groupe de consommateurs, Kafka garantit que chaque message dans une rubrique est en lecture seule une fois par un consommateur (ce qui est similaire à un système Message Queue). Les avantages supplémentaires sont que les messages sont conservés par les courtiers (ce qui le rend ainsi tolérant aux pannes pendant un certain temps) et si nous avons plusieurs groupes de consommateurs, ils peuvent lire les messages du même sujet mais les traiter différemment.
Implication de cas d'utilisation
Supposons que nous ayons une plate-forme cloud simple où nous autorisons les opérations suivantes aux utilisateurs:
- Stockez des fichiers dans le cloud.
- Affichez leurs fichiers dans le cloud.
- Téléchargez leurs fichiers depuis le Cloud.
Au début, nous avions une très petite base d'utilisateurs. Nous voulions dériver diverses statistiques (sur une base horaire) comme les utilisateurs actifs, le nombre de demandes de téléchargement, le nombre de demandes de téléchargement, etc. Pour répondre aux exigences, nous avons mis en place un cluster Kafka qui produit les journaux (générés par notre application) dans un sujet et il existe une application qui consomme le sujet (à l'aide d'un consommateur), puis le traite pour générer les statistiques requises et enfin afficher ceux d'une page Web.
Comme les gens ont commencé à aimer nos services, de plus en plus de personnes ont commencé à l'utiliser, générant ainsi beaucoup de journaux par heure. Nous avons constaté que l'application qui consomme le sujet est devenue extrêmement lente car nous n'utilisions qu'un seul consommateur. Afin de résoudre le problème, nous avons ajouté quelques consommateurs au groupe et constaté une amélioration significative des performances.
Nous sommes tombés sur une autre exigence, où nous devions écrire les journaux dans un cluster HDFS et ce processus devrait s'exécuter indépendamment de l'application précédente (En effet, avec une augmentation supplémentaire des données, nous prévoyions de mettre hors service la première application et de dériver toutes les statistiques dans l'environnement HDFS). Pour répondre à cette exigence, nous avons développé une autre application qui s'est abonnée au sujet en utilisant un groupe de consommateurs différent et a écrit les données dans le cluster HDFS.
Articles recommandés
Ceci est un guide pour Kafka Consumer Group. Ici, nous discutons de l'importance du groupe de consommateurs Kafka et comment Kafka relie deux modèles avec son implication dans le cas d'utilisation. Vous pouvez également consulter les articles suivants pour en savoir plus-
- Applications Kafka
- Comment installer Kafka?
- Questions d'entretiens chez Kafka
- Architecture HDFS
- Différents types d'outils Kafka