Что происходит с идемпотентностью, когда производитель Кафки перезапускается или выходит из строя?

Question

Похоже, что дедупликация выполняется брокером Kafka путем отслеживания сообщений на уровне раздела:

1. порядковый номер сообщения
2. идентификатор производителя

Все, что я читаю, говорит об этом, решая проблему ошибки производителя или брокера, которая приводит к тому, что производитель повторяет отправку. Как насчет того, когда продюсер уйдет? Является ли идентификатор производителя статическим идентификатором, контролируемым мной, или он назначается посредником при каждой регистрации узла производителя? Если идентификатор производителя переназначен и отличается от того, каким он был до перезапуска, это может привести к дублированию, верно?

Я не понимаю, почему они так разработали идентификатор производителя, но я не могу найти PRODUCER_ID_CONFIG в org.apache.kafka.clients.producer.ProducerConfig, так что похоже, что он был спроектирован.

Answer 1

В этом сценарии есть дублирование. Я не уверен, почему PID был разработан, чтобы быть временным, а не постоянным между сессиями, но из реализованного предложения :

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

Редактировать: похоже, что эта проблема решена с помощью TransacitonalId, который равен , предоставленным мной. Это подробно описано в том же документе, ссылка на который есть выше.