Dans Apache Kafka, pourquoi ne peut-il pas y avoir plus d'instances de consommateurs que de partitions?
J'apprends à propos de Kafka, en lisant la section d'introduction ici
https://kafka.Apache.org/documentation.html#introduction
en particulier la partie sur les consommateurs. Dans l'avant-dernier paragraphe de l'introduction, on lit
Kafka le fait mieux. En ayant une notion de parallélisme - la partition - dans les sujets, Kafka est capable de fournir à la fois des garanties de commande et un équilibrage de charge sur un ensemble de processus consommateurs. Ce est obtenu en attribuant les partitions du sujet aux consommateurs du groupe de consommateurs de sorte que chaque partition est consommée par exactement un consommateur du groupe. En faisant cela, nous nous assurons que le Le consommateur est le seul lecteur de cette partition et consomme les données dans l’ordre. Puisqu'il y en a beaucoup partitions cela équilibre toujours la charge sur de nombreuses instances de consommateurs. Notez cependant qu'il ne peut pas être plus d'instances de consommateurs que de partitions.
Ma confusion découle de cette dernière phrase, car dans l'image juste au-dessus de ce paragraphe où l'auteur décrit deux groupes de consommateurs et un sujet à 4 partitions, il y a plus d'instances de consommateurs que de partitions!
Cela n'a également aucun sens de penser qu'il ne peut y avoir plus d'instances de consommateurs que de partitions, car les partitions seraient alors incroyablement petites et il semblerait que la surcharge liée à la création d'une nouvelle partition pour chaque instance de consommateur enlève Kafka. Je comprends que les partitions servent à la tolérance aux pannes et à la réduction de la charge sur un serveur, mais la phrase ci-dessus n’a aucun sens dans le contexte d’un système distribué censé pouvoir gérer des milliers de consommateurs à la fois.
Ok, pour le comprendre, il faut comprendre plusieurs parties.
- Afin de fournir un ordre total de commande, le message ne peut être envoyé qu’à un seul consommateur. Sinon, cela serait extrêmement inefficace, car il faudrait attendre que tous les consommateurs reçoivent le message avant d’envoyer le message suivant:
Toutefois, bien que le serveur distribue les messages dans l’ordre, ceux-ci sont remis aux consommateurs de manière asynchrone, de sorte qu’ils risquent d’arriver en panne sur différents consommateurs. Cela signifie effectivement que l'ordre des messages est perdu en présence d'une consommation parallèle. Les systèmes de messagerie contournent souvent cela en ayant une notion de "consommateur exclusif" qui permet à un seul processus de consommer depuis une file d'attente, mais bien entendu, cela signifie qu'il n'y a pas de parallélisme dans le traitement.
Kafka le fait mieux. En intégrant une notion de parallélisme (la partition) dans les rubriques, Kafka est en mesure de fournir à la fois des garanties de commande et un équilibrage de la charge sur un ensemble de processus de consommation. Pour ce faire, vous affectez les partitions du sujet aux consommateurs du groupe de consommateurs, de manière à ce que chaque partition soit consommée par un seul consommateur du groupe. En faisant cela, nous nous assurons que le consommateur est le seul lecteur de cette partition et consomme les données dans l’ordre. Comme il existe de nombreuses partitions, la charge reste équilibrée entre plusieurs instances de consommateurs. Notez cependant qu'il ne peut y avoir plus d'instances de consommateurs que de partitions.
Kafka fournit uniquement un ordre total sur les messages d'une partition, pas entre différentes partitions d'une rubrique.
De plus, ce que vous pensez être une pénalité de performances (plusieurs partitions) est en réalité un gain de performances, car Kafka peut effectuer des actions de différentes partitions complètement en parallèle, en attendant que les autres partitions soient terminées.
- La photo montre différents groupes de consommateurs, mais la limite d'un consommateur par partition est limitée à un groupe. Vous pouvez toujours avoir plusieurs groupes de consommateurs.
Au début, les deux scénarios sont décrits:
Si toutes les instances de consommateurs ont le même groupe de consommateurs, cela fonctionne comme une charge d'équilibrage de file d'attente traditionnelle sur les consommateurs.
Si toutes les instances de consommateurs ont des groupes de consommateurs différents, cela fonctionne comme si vous publiez-vous abonnez-vous et tous les messages sont diffusés à tous les consommateurs.
Ainsi, plus vous avez de groupes d’abonnés, moins les performances sont bonnes, car kafka doit répliquer les messages sur tous ces groupes et garantir l’ordre total.
D'autre part, moins il y a de groupes et plus vous avez de partitions, plus vous gagnez à mettre en parallèle le traitement des messages.
Il est important de rappeler que Kafka conserve un décalage par [groupe de consommateurs, sujet, partition]. C'est la raison.
Je devine la phrase
Notez cependant qu'il ne peut y avoir plus d'instances de consommateurs que de partitions.
fait référence au mode "rééquilibrage automatique du groupe de consommateurs", le mode de consommateur par défaut lorsque vous vous abonnez () à un certain nombre de consommateurs à une liste de sujets.
Je suppose que, parce que, du moins avec Kafka 0.9.x, rien n’empêche d’avoir plusieurs instances de consommateurs, membres du même groupe, lisant à partir de la même partition.
Vous pouvez faire quelque chose comme ça dans deux ou plusieurs threads différents
Properties props = new Properties();
props.put(ConsumerConfig.GROUP_ID_CONFIG, "MyConsumerGroup");
props.put("enable.auto.commit", "false");
consumer = new KafkaConsumer<>(props);
TopicPartition partition0 = new TopicPartition("mytopic", 0);
consumer.assign(Arrays.asList(partition0));
ConsumerRecords<Integer, String> records = consumer.poll(1000);
et vous aurez deux (ou plus) consommateurs lisant à partir de la même partition.
Maintenant, le "problème" est que les deux consommateurs vont partager le même décalage, vous n'avez pas d'autre option car il n'y a qu'un seul groupe, sujet et partition en jeu.
Si les deux consommateurs lisent le décalage actuel en même temps, ils liront la même valeur et les deux recevront les mêmes messages.
Si vous voulez que chaque consommateur lise des messages différents, vous devrez les synchroniser afin qu'un seul puisse extraire et valider l'offset à la fois.
Il y a une raison pour laquelle Kafka ne peut pas prendre en charge plusieurs consommateurs par partition.
Kafka broker écrit les données dans le fichier par partition. Supposons donc que si deux partitions sont configurées, le courtier crée deux fichiers et affecte plusieurs groupes de consommateurs auxquels les messages peuvent être envoyés.
Désormais, pour chaque partition, un seul consommateur consomme des messages en fonction du décalage du fichier. Par exemple, le consommateur 1 lira d’abord les messages du décalage de fichier 0 à 4096. Maintenant, ces décalages font partie de la charge utile afin que le client sache quel décalage utiliser lors de la demande de lecture des prochains messages.
Si plusieurs consommateurs lisent sur la même partition, le consommateur 1 lit le fichier avec le décalage 0-4096 mais le consommateur 2 essaiera toujours de lire le décalage 0 sauf s'il reçoit également le message envoyé au consommateur 1.. Kafka les a divisés en groupes de consommateurs afin que tous les groupes de consommateurs puissent recevoir des messages, mais qu’au sein d’un groupe de consommateurs, un seul consommateur peut recevoir des messages.
Dans Kafka, une seule instance de consommateur peut utiliser les messages d'une partition. Si les instances de consommateur sont plus que des partitions, aucune instance de consommateur supplémentaire ne sera utilisée. Donc, kafka n'autorise pas ces instances de consommateurs supplémentaires.
À présent, si plusieurs consommateurs peuvent utiliser une partition, la consommation de messages ne sera pas ordonnée. C'est la raison pour laquelle kafka n'autorise pas plusieurs consommateurs par partition.
Le modèle de groupe de consommateurs Kafka est un hybride de mécanisme de mise en file d'attente dans lequel le message lu une fois par une instance de consommateur est immédiatement supprimé de la file d'attente et d'un mécanisme pub/sous dans lequel le message n'est pas supprimé jusqu'à la fin du délai de conservation défini toutes les instances de consommateurs jusqu'à leur expiration. Ainsi, si vous souhaitez utiliser un modèle pub/sous mais que vous souhaitez l'exploiter en tant que mécanisme de mise en file d'attente, vous créez un groupe de consommateurs pour toutes vos instances de consommateurs. Étant donné que Kafka distribue des partitions parmi les instances de consommateurs d'un même groupe de consommateurs, il est garanti qu'un message n'est traité qu'une seule fois. Si Kafka vous permet d'avoir plus d'instances de consommateurs au sein d'un même groupe de consommateurs, alors l'objectif du groupe de consommateurs est dépassé.
Considérons cet exemple:
L'API REST pub1 a publié 4 messages dans la rubrique 1 comportant 4 partitions part1 à part4, de sorte que chaque partie comporte 1 message.
Vous avez 2 microservices sub1 et sub2 en tant qu'abonnés et 4 instances de chaque microservices en cours d'exécution.
Maintenant, si vous créez 2 groupes de consommateurs, un pour chaque miroservice Sub1instance1 sera mis en correspondance avec part1, sub1instance2 sera mis en correspondance avec part2, etc.
Tant que vos instances de consommateurs dans chaque groupe de consommateurs sont inférieures ou égales au nombre de partitions, chaque instance de votre microservice ne traitera le message qu'une seule fois. Dans ce cas, sub1instance1 et sub2instance traiteront msg1 de part1.
Si le nombre d'instances de consommateurs est supérieur au nombre de partitions, Kafka devra affecter les mêmes partitions à plusieurs instances de consommateurs afin que les messages soient traités plusieurs fois par chaque instance de consommateur mappée sur cette partition. C'est la raison pour laquelle Kafka nous empêche d'avoir plus d'instances de consommateurs dans un groupe de consommateurs que le nombre de partitions dans un sujet auquel le groupe de consommateurs est abonné.
J'espère que cela a du sens.