Я застрял в типичном варианте использования или сценарии, когда я не уверен, как будет себя вести Kafka ..
SCENERIO : I am using Spring Kafka with spring Boot. In my application I am having one Rest end point which will read all messages from the beginning of a topic to check for the duplication of message then write to topic if not duplicate.
Я не понимаю, каким будет поведение приложения при развертывании нескольких экземпляров одного и того же микросервиса и перемещении смещения для операции seekFromBegining.
у меня в голове несколько вопросов:
do reading from beginning of a topic (with the help of seek) block the topic ?
If Yes. then how to solve this typical use case where we have to validate for the
duplication of message before writing to the topic.
Использование БД не является решением, потому что это требует значительных ресурсов. и замедлить работу приложения.
Спасибо всем заранее




Похоже, вам нужна функция Сжатие журнала:
Log compaction ensures that Kafka will always retain at least the last known value for each message key within the log of data for a single topic partition.
Поэтому, когда вы указываете несколько уникальных message key, у вас не будет больше одного из них в разделе. И при этом вам вообще не нужно читать тему перед сохранением.
Ну, это как-то не связано с историей. Я предложил вам совершенно другое решение, которое поставляется в виде готового решения в Kafka. Я просто не вижу причин читать что-либо из этой службы REST, если вы можете решить проблему дублирования с помощью сжатия журнала.
Спасибо !!! Я обязательно рассмотрю функцию сжатия журнала. это также может помочь нам удалить дубликаты. но проверка необходима, чтобы приложение, использующее конечную точку отдыха, получало уведомление о дублировании сообщения.
Блокировок по теме нет. Вы просто создаете KafkaConsumer с уникальной группой потребителей каждый раз и используете auto.offset.reset как earliest. Таким образом, эта новая группа всегда будет читать тему с самого начала и никогда не будет сталкиваться с другими группами по той же теме. Но функция сжатия журналов по-прежнему будет. Это уже функция производителя, а не потребителя.
Да, мы используем ключи при записи в Kafka Topics. Означает ли это, что тема не будет заблокирована одним экземпляром при чтении.