Возможны повторная публикация производителем, повторная доставка после сбоя до подтверждения или повторный вызов в приложении. Сравните ID бизнес-операции, сообщения, доставок и моменты ack/commit. Обработка at-least-once допускает повтор; debounce и отключение подписчика не заменяют устойчивую идемпотентность.
Почему одно сообщение могло дважды попасть в обработчик?
Разные причины дубликата: повторная публикация, повторная доставка и двойной вызов. Как установить механизм по идентификаторам и подтверждениям.
Короткий ответ
Что ответить на собеседовании
Подробный разбор
Ответ с пояснениями
Не начинайте с уверенного рассказа о причине, пока не установлено, какие именно два события наблюдались.
Три типичных механизма:
- Производитель не получил подтверждение и повторно опубликовал ту же бизнес-операцию.
- Потребитель выполнил действие, но завершился до ack или фиксации позиции; брокер доставил сообщение повторно.
- Код приложения зарегистрировал обработчик дважды либо сам повторно вызвал его.
Для расследования сопоставьте ID операции и сообщения, журнал публикации, позицию или delivery metadata, подтверждения и рестарты. Два разных ID сообщения могут относиться к одной операции; одинаковый текст ещё не доказывает дубль.
RabbitMQ прямо описывает необходимость учитывать повторную доставку и повторную публикацию. Факт повтора при at-least-once сам по себе не означает поломку брокера.
Исправление зависит от причины: убрать лишнюю подписку, обеспечить стабильный ID операции и атомарную регистрацию результата, согласовать подтверждение с сохранением состояния. Для внешних побочных эффектов нужны поддерживаемые получателем ключи идемпотентности либо иной протокол согласования.
Debounce ограничивает частоту вызовов в конкретном процессе, но не защищает от повторов после сбоя или на другом узле. В рассказе о своём инциденте отделите возможные объяснения от причины, подтверждённой фактами.