Сначала обработать, потом зафиксировать offset (или подтвердить сообщение). Если упасть между обработкой и фиксацией, сообщение придёт снова — отсюда дубли, и обработка должна быть идемпотентной.
А ещё Exactly-once внутри Kafka — транзакции; с внешней базой — offset и результат в одной транзакции
Так подсказку видит пользователь sotto на живом собеседовании — за пару секунд, пока вы думаете вслух.
Порядок действий определяет гарантию:
Для бизнес-событий почти всегда выбирают at-least-once и делают обработку идемпотентной: дубль безвреден, потеря — нет.
Автокоммит (enable.auto.commit=true) фиксирует offset периодически при очередном poll() — не привязан к завершению обработки. Если обработка асинхронная или пакетная, можно закоммитить ещё не обработанное (потеря) или не закоммитить обработанное (дубли). Для надёжности — ручной коммит после обработки (в Spring Kafka — AckMode.RECORD/BATCH/MANUAL).
Откуда ещё дубли: ребаланс — партицию забрали до коммита, и новый потребитель начнёт с последнего зафиксированного offset; повтор продюсера без идемпотентности; повторная публикация из outbox.
Защита: идемпотентность по id сообщения (таблица обработанных в той же транзакции), естественно идемпотентные операции (UPSERT, установить статус), хранение offset вместе с результатом в базе.
Один верный вариант. Подумайте, потом откройте ответ.
Зачем брокер сообщений, queue против pub/sub, три семантики доставки, роль идемпотентности и компромисс порядок/масштаб.
sotto слышит вопрос интервьюера и показывает короткий ответ и план, как в блоке «Коротко». Оставьте контакт — пришлём доступ и промокод.
sotto