Гарантии доставки в Kafka
Вопрос
Как в пайплайне Kafka → обработка → база данных добиться, чтобы события не терялись и не задваивались?
Попробуйте сами
Ответьте вслух за 2 минуты, как на собесе. Потом сверьтесь с тезисами: что прозвучало, а что нет.
Показать ответ и разбор
Коротко
Что должно прозвучать в ответе
Продюсер: acks=all, min.insync.replicas, идемпотентность, ретраи
Репликация с фактором 3
Консьюмер: коммит оффсета после обработки, at-least-once
Идемпотентная запись в базу: upsert по ключу или таблица обработанных id
Транзакции Kafka для read-process-write внутри Kafka
Мониторинг lag и ошибок, DLQ для плохих сообщений
Что могут спросить следом
- Почему нельзя просто включить exactly-once в консьюмере?
- Что делать с сообщением, которое всегда падает при обработке?
Разбор
Образцовый ответ: «На записи: продюсер с acks=all, идемпотентностью и ретраями, топик с фактором репликации 3 и min.insync.replicas=2, тогда подтверждённое сообщение переживёт падение брокера. На чтении: коммит оффсета только после успешной записи в базу, это at-least-once, значит, возможны повторы. Повторы гашу на стороне базы: запись идемпотентна, upsert по естественному ключу или проверка id события в таблице обработанных в той же транзакции, что и сама запись. Если вся обработка внутри Kafka, можно использовать транзакции Kafka. Сообщения, которые стабильно падают, после нескольких попыток уходят в dead letter topic, чтобы не блокировать партицию. И мониторю lag, ошибки и объём DLQ».
Ответьте сами, а не прочитайте
В тренажёре вопрос попадёт в повторения и вернётся, когда начнёт забываться. Плюс билеты с зачётом: 20 вопросов, не больше 2 ошибок.