Стратегии для обеспечения того, чтобы у каждого потребителя Kafka был свой уникальный / уникальный group.id для реализации публикации-подписки - PullRequest
0 голосов
/ 16 октября 2018

Я пытаюсь реализовать модель публикации-подписки с Kafka, где одна тема будет прочитана / использована многими независимыми потребителями.

Насколько я понимаю, каждый потребитель идентифицирует себя как уникального подписчика, используя уникальный group.id

Однако злонамеренный или неисправный потребитель B может получить сообщение потребителя A, если потребитель B сообщает об этом.он сам с тем же group.id, что и потребитель A. Таким образом, сообщения будут распределяться между Потребителем A и B, что нежелательно.

Существуют ли какие-либо механизмы или стратегии Кафки, чтобы предотвратить это?

Я не смог найти никого, кто бы обсуждал этот вопрос;меня удивляет, если я неправильно понял group.ids или есть какое-то очевидное решение, которое я пропустил.Извините, если это нубский вопрос, но большое спасибо за ваше время!

1 Ответ

0 голосов
/ 16 октября 2018

То, что вы хотите, называется Назначение разделов вручную .В этом режиме автоматическая перебалансировка потребителя отключена, поэтому вы полностью контролируете, из какой темы / разделов вы потребляете, и ни один потребитель не может «украсть» ваши сообщения, даже если они используют одну и ту же группу потребителей.Я бы.Конечно, недостатком является то, что в случае отказа какого-либо из потребителей не происходит автоматического перебалансирования потребителей.

Из официальных Javadocs (выделено мое):

Чтобы использовать этот режимвместо подписки на тему с помощью подписки вы просто вызываете assign (Collection) с полным списком разделов, которые вы хотите использовать.

 String topic = "foo";
 TopicPartition partition0 = new TopicPartition(topic, 0);
 TopicPartition partition1 = new TopicPartition(topic, 1);
 consumer.assign(Arrays.asList(partition0, partition1));   Once assigned, you can call poll in a loop, just as in the preceding

примеры использования записей.Группа, которую указывает потребитель, все еще используется для фиксации смещений, но теперь набор разделов будет меняться только при другом вызове для назначения. При ручном назначении разделов не используется координация групп, поэтому сбои потребителей не приведут к перебалансированию назначенных разделов.Каждый потребитель действует независимо, даже если он разделяет groupId с другим потребителем. Чтобы избежать конфликтов смещения фиксации, обычно следует убедиться, что groupId уникален для каждого экземпляра потребителя.

Полные документы здесь (ищите Ручное присвоение разделов раздел): https://kafka.apache.org/20/javadoc/org/apache/kafka/clients/consumer/KafkaConsumer.html

...