Вопрос по которому часто возникают трудности у кандидатов😐

«Как вы боретесь с дублями в Kafka на проде?». Напиши свой ответ в комментариях и сравнивай:

Ответ: "Три уровня защиты. Producer: enable.idempotence=true — закрывает сетевые ретраи. Consumer: проверяю event_id в Postgres перед обработкой. Транзакции — только для read-process-write между топиками Kafka. Главное правило: check → process → commit offset."

Совпало? Теперь разберем по полочкам, почему это важно: 👇

Почему дубли вообще есть?

1️⃣Producer retry
Producer отправил сообщение → брокер не ответил → producer отправил СНОВА
Kafka получила 2 одинаковых сообщения

2️⃣Consumer crash
Consumer прочитал сообщение → начал обработку → УПАЛ
При рестарте читает то же сообщение СНОВА

3️⃣Rebalance группы (80% проблем на проде!)
Consumer A обработал партицию → Consumer B взял её → обработал СНОВА

Как это можно решить:

🔵Настройка продюсера

Кафка выдает тебе Producer ID (PID) и заставляет нумеровать сообщения. Если брокер видит сообщение с номером, который уже был - он его просто выкидывает.

Настройка: enable.idempotence=true.

Почти не влияет на скорость. Включай всегда по умолчанию.

🔵Транзакции

Объединяет чтение и запись в одну неделимую операцию (Read-Process-Write). Если что-то упало - вся цепочка откатится, и дублей в конечном топике не будет.

Настройка: transactional.id + isolation.level=read_committed.

Добавляет задержку (latency). Используй только там, где критичен идеальный порядок.

🔵 Идемпотентность консьюмера

Кафка не знает, что в твоей базе. Если сервис записал данные, но «упал» до фиксации оффсета - кафка пришлет дубль. Поэтому проверяй уникальность ключа на входе в базу.

Пример: INSERT ... ON CONFLICT DO NOTHING в Postgres или SET NX в Redis.

Самый надежный способ, который спасет, даже если настройки кафки не помогли.

🤔Какой следующий вопрос разобрать?

#Kafka #DataEngineering #ITCareer #CareerDE #DataScience