☀Объяснение: 1. Почему возникает дублирование? В Kafka потребитель (consumer) фиксирует смещение (offset) прочитанного сообщения либо автоматически (настроенный интервал авто-коммита), либо вручную. Если авто-коммит происходит до того, как сообщение полностью обработано (например, после чтения, но до записи в базу), и сервис падает, то после перезапуска смещение уже зафиксировано, и сообщение теряется. Если авто-коммит происходит после обработки — всё хорошо. Но в случае сбоя в середине обработки, смещение не фиксируется, и при перезапуске потребитель прочитает то же сообщение снова. Так возникает at-least-once семантика. 2. Решение — ручное управление смещениями java // Пример на Java while (true) { ConsumerRecords<String, Order> records = consumer.poll(Duration.ofMillis(1000)); for (ConsumerRecord<String, Order> record : records) { processOrder(record.value()); // может выбросить исключение } // Фиксируем смещение ТОЛЬКО после успешной обработки всех сообщений в батче consumer.commitSync(); } Если processOrder упадёт, исключение не даст дойти до commitSync(), и при следующем опросе потребитель получит те же сообщения. Это обеспечивает at-least-once — каждое сообщение будет обработано минимум один раз. Для строгой exactly-once нужно сочетать идемпотентность обработки и транзакции Kafka (Kafka Transactions). 3. Почему другие варианты не подходят? B (увеличить retention): Не влияет на дублирование. Retention определяет, как долго сообщения хранятся, а не как часто они обрабатываются. C (увеличить партиции): Увеличивает параллелизм, но не решает проблему фиксации смещений. Дублирование остаётся. D (синхронная отправка с подтверждением): Речь о продюсере, но проблема у потребителя. Даже если сообщение отправлено синхронно, потребитель всё равно может обработать его дважды при авто-коммите. 4. Что должен заложить аналитик в требования? Семантика доставки: выбрать at-least-once (с идемпотентной обработкой) или exactly-once (с транзакциями). Идемпотентность потребителя: бизнес-операции должны быть спроектированы так, чтобы повторная обработка не приводила к ошибкам (например, проверка уникального идентификатора сообщения). Мониторинг: отслеживать лаг (lag) потребителя, чтобы вовремя заметить проблемы. 5. Реальный кейс В логистической компании после миграции на Kafka авто-коммит был настроен на 5 секунд. При падении сервиса на 10 секунд обрабатывались сотни заказов дважды. Водители получали дубликаты маршрутов, система учёта списывала товар дважды. Переход на ручной коммит и внедрение идемпотентности (поиск уже обработанного заказа по orderId) решили проблему. Вывод: Контроль над смещениями и идемпотентность — критически важны для надёжной работы потребителей в Kafka. Аналитик обязан закладывать эти требования, чтобы избежать потери или дублирования данных. 🎯