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

Вопрос по которому часто возникают трудности у кандидатов 😐 «Как вы боретесь с дублями в 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