Что проверяет вопрос про exactly-once в Kafka

Вопрос обычно звучит так: как Kafka гарантирует, что сообщение будет обработано ровно один раз, а не потеряется и не задвоится. Проверяют не знание одной настройки, а понимание, что exactly-once — это связка из нескольких механизмов, а не флаг в конфиге.

enable.idempotence=true убирает дубли от повторной отправки одного и того же батча producer'ом при retry на сети. Это часть картины, но не всё: если producer пишет в несколько партиций или топиков в рамках одной бизнес-операции, нужен транзакционный producer с transactional.id — он оборачивает запись во все партиции и коммит offset'а в одну атомарную транзакцию.

Со стороны consumer'а есть отдельная настройка, про которую часто забывают: isolation.level. По умолчанию она read_uncommitted — consumer видит записи из транзакций, даже если они потом были прерваны (aborted). Чтобы consumer видел только закоммиченные транзакции, нужно явно поставить read_committed.

Properties props = new Properties(); props.put("isolation.level", "read_committed"); props.put("enable.auto.commit", "false");

Ловушка: включили транзакционный producer, протестировали на happy path — работает. В проде часть транзакций прерывается из-за таймаутов, а consumer с дефолтным read_uncommitted спокойно читает эти прерванные записи как обычные. Дубли и мусор в данных находят через недели, не на код-ревью.

Exactly-once в Kafka — это транзакции на стороне producer'а и явный isolation level на стороне consumer'а одновременно. Пропустить любую из двух половин — получить at-least-once с дублями под видом exactly-once.

Тренажёр: 600 вопросов, мок с таймером, план повторов

senior·base — что спрашивают на самом деле

В этом посте были ссылки, но мы их удалили по правилам Сетки