Consumer подтверждает сообщение до сохранения результата: как исключить потерю данных

Ack означает обещание, что сообщение больше не нужно доставлять. Если код отправляет подтверждение до commit базы, загрузки файла или записи outbox, короткий сбой создаёт тихую потерю. Перенос ack в конец важен, но без идемпотентности приводит к другой проблеме — повторному применению действия.

Возьмите одно тестовое сообщение со стабильным message ID. Добавьте контролируемое завершение процесса между ключевыми шагами: до записи, после записи и до ack. Затем проверьте broker, базу и внешние действия. Такой fault-injection быстрее обычных логов показывает реальную гарантию обработки.

Что проверить в первую очередь

Для проблемы «consumer подтверждает сообщение раньше надёжного сохранения результата» сначала зафиксируйте один воспроизводимый пример: точное время, идентификатор объекта, пользователя или операции, входные данные, версию приложения и фактический результат. Отдельно запишите ожидаемое поведение: подтверждение или смещение offset происходит только после устойчивой фиксации результата, а повторная доставка безопасна благодаря идемпотентному обработчику. Это не формальность. Без исходной точки легко принять временное совпадение за исправление, изменить сразу несколько условий и потерять возможность доказать настоящую причину сбоя.

Проверку начинайте с чтения состояния и журналов. Не запускайте массовый перерасчёт, повторную отправку, удаление записей или изменение прав на рабочей системе, пока не подготовлены резервная копия и способ отката. Секреты, токены, персональные данные и содержимое заказов в диагностические выгрузки не включайте.

• Уточните auto-ack, manual ack или модель commit offsets.
• Определите точку, после которой результат действительно устойчив.
• Проверьте транзакции базы и внешние вызовы между записью и ack.
• Найдите стабильный business key или message ID для дедупликации.
• Посмотрите requeue, retry policy, visibility timeout и dead-letter queue.

Почему возникает проблема

Видимый симптом обычно находится в конце цепочки. Пользователь видит неверный статус или отказ, хотя первичная ошибка могла произойти в API, фоновой задаче, кеше, очереди, внешнем сервисе либо при проверке доступа. Основной риск этого сценария: процесс падает после ack, broker считает сообщение обработанным, а бизнес-изменение исчезает без возможности автоматического повтора. Поэтому исправление только интерфейса или ручная правка итоговой записи часто скрывает проблему, но не устраняет её.

Разбирайте события по хронологии и ищите первую точку, где фактические данные перестают соответствовать бизнес-правилу. В распределённой системе одинаково важны успешный ответ, повтор запроса, задержка события, параллельное выполнение и восстановление после временного отказа.

• Библиотека включает auto-ack по умолчанию.
• Offset коммитится пакетно раньше завершения всех сообщений batch.
• Обработчик подтверждает сообщение в finally независимо от исключения.
• Результат записан в память или локальный временный файл, но ещё не сохранён устойчиво.
• Внешнее действие выполнено, а идемпотентный ключ не записан вместе с состоянием.

Пошаговая диагностика

Создайте безопасный тестовый сценарий, максимально похожий на проблемный, но не затрагивающий реальные списания, рассылки и клиентские данные. Присвойте операции единый correlation ID и проследите его через входящий запрос, бизнес-логику, базу, очередь и внешние интеграции. Для каждого этапа фиксируйте вход, результат, код ответа, время выполнения и номер версии записи.

Сначала подтвердите сам факт расхождения, затем последовательно исключайте уровни. Сравните рабочий и ошибочный случаи по одним и тем же полям. Проверьте часовой пояс, формат идентификаторов, порядок событий, права сервисной учётной записи и актуальность конфигурации на каждом экземпляре приложения. Если результат зависит от повторного запроса, задержки или конкретного узла, это важная часть причины, а не случайный шум.

• Сопоставьте delivery tag или offset, message ID и commit бизнес-транзакции.
• Проверьте логи graceful shutdown и принудительного завершения.
• Остановите consumer после ack, но до искусственно задержанного commit.
• Найдите пропуски последовательности событий и сообщения без соответствующей записи.
• Сравните настройки prefetch, batch size и время обработки с timeout broker.

Как реализовать обработку at-least-once

Практичная модель предполагает возможную повторную доставку. Consumer атомарно фиксирует бизнес-результат и маркер обработанного сообщения, а затем подтверждает broker. Внешние побочные действия запускаются через outbox.

Надёжная реализация хранит бизнес-состояние явно и не пытается восстановить его только по экрану, случайному логу или последнему webhook. У каждого значимого действия должен быть стабильный идентификатор, понятный владелец, версия правила и проверяемый переход статуса. Повторная доставка одного события не должна создавать второе действие, а запоздавшее событие не должно возвращать объект в невозможное состояние.

• Message ID или business key имеет уникальное ограничение в базе.
• Изменение состояния и запись processed message выполняются в одной транзакции.
• Outbox создаётся в той же транзакции и публикуется отдельным worker.
• Ack отправляется после успешного commit.
• Неисправимые сообщения переходят в DLQ с причиной и инструментом безопасного повтора.

Как исправить проблему

Исправление разделите на небольшие обратимые изменения. Сначала устраните подтверждённую первопричину, затем восстановите повреждённые данные отдельной контролируемой процедурой. Не смешивайте выпуск нового кода и массовую коррекцию истории в одном непрозрачном запуске: для них нужны разные отчёты, критерии успеха и планы отката.

Если затронуты существующие записи, сначала сформируйте dry-run: список объектов, старое значение, предлагаемое новое значение и основание для изменения. Обновление должно быть идемпотентным, ограниченным точной выборкой и сопровождаться аудитом. Для финансовых данных, прав доступа и персональной информации предпочтительны компенсирующие записи, а не переписывание истории.

• Отключите auto-ack и перенесите подтверждение после устойчивого commit.
• Добавьте уникальный idempotency key и обработку повторной доставки как успешного no-op.
• Не вызывайте внешние API внутри транзакции без отдельной стратегии согласованности.
• Используйте outbox для последующих событий и inbox для входной дедупликации.
• Настройте ограниченный retry с backoff и наблюдаемую DLQ.

Безопасный порядок внедрения

• Сохраните конфигурацию, связанные записи и необходимые журналы; отдельно проверьте, что резервную копию действительно можно восстановить.
• Воспроизведите проблему на тестовом объекте и сохраните результат до изменения, чтобы после выпуска сравнить одинаковые сценарии.
• Внесите минимальное изменение под системой контроля версий, опишите причину, ожидаемый эффект, ограничения и точный способ отката.
• Прогоните нормальный сценарий, ошибочный ввод, повтор одного запроса, два параллельных запроса и временную недоступность зависимости.
• Выпустите изменение на ограниченную долю трафика или один процесс, если архитектура это позволяет, и сравните метрики со старой версией.
• Только после стабильного наблюдения выполните контролируемое исправление исторических данных и сохраните итоговый отчёт.

Как проверить результат

Один успешный пример недостаточен. Проверьте основную операцию повторно, крайние значения, одновременные действия, перезапуск процесса и восстановление после краткого сбоя сети. Результат подтверждайте не только экраном пользователя, но и состоянием базы, очереди, внешнего сервиса и журналом аудита. Особое внимание уделите тому, что система делает при повторной доставке уже обработанного события.

Критерии приёмки сформулируйте до выпуска. Каждый пункт должен давать однозначный ответ «выполнено» или «не выполнено», а не субъективную оценку. Если тест невозможно повторить автоматически, оставьте короткий регрессионный чек-лист с тестовыми данными и ожидаемыми статусами.

• Падение до commit приводит к повторной доставке без частичного результата.
• Падение после commit до ack приводит к повтору, который не дублирует действие.
• Два consumer одновременно обрабатывают одинаковый business key безопасно.
• Временная ошибка возвращается в retry с ограничением попыток.
• Неисправимое сообщение попадает в DLQ вместе с достаточным контекстом без секретов.

Типичные ошибки при исправлении

• Перенести ack в конец, но оставить неидемпотентные списания и письма.
• Считать exactly-once свойством одного флага broker для всей бизнес-цепочки.
• Бесконечно requeue неисправимое сообщение.
• Подтверждать весь batch после частичного успеха без учёта отдельных offsets.
• Удалять DLQ без отчёта и исправления причины.

Опаснее всего исправление, которое убирает заметный симптом ценой отключения проверки, ослабления прав или потери аудита. Такое изменение может сделать интерфейс «зелёным», но увеличить ущерб при следующем сбое. Если временный обход всё же необходим, ограничьте его срок, пользователей и область действия, добавьте мониторинг и заранее назначьте дату удаления.

Как предотвратить повторение

Профилактика строится вокруг явных контрактов, идемпотентных обработчиков, наблюдаемости и повторяемых релизов. Система должна не только корректно работать сейчас, но и быстро показывать нарушение правила после обновления, роста нагрузки или отказа интеграции. Ошибку, которая уже привела к потере времени, денег, данных или заявок, стоит закрепить автоматическим тестом.

Настройте мониторинг полного пользовательского пути, а не только доступности отдельных серверов. Техническая метрика должна быть связана с бизнес-результатом: заказ завершён, доступ выдан, файл восстановлен, событие обработано один раз, данные изолированы. Порог оповещения задавайте по нормальному профилю нагрузки и проверяйте, что уведомление содержит достаточно контекста для первого решения.

• Сообщения без соответствующего бизнес-результата и результаты без source message ID.
• Redelivery rate и причины повторов.
• Возраст retry и размер DLQ.
• Конфликты уникального idempotency key как контролируемый сигнал дубля.
• Время между commit результата и ack или offset commit.

Что подготовить для технического разбора

• Короткое описание ожидаемого и фактического поведения с точной последовательностью действий.
• Время возникновения, идентификатор тестового объекта и версии всех затронутых компонентов.
• Обезличенные фрагменты журналов до и после ошибки с единым correlation ID.
• Список последних изменений, результаты уже выполненных проверок и условия, при которых симптом исчезает.
• Безопасный доступ к тестовой среде либо минимальный пример, не содержащий паролей, токенов и персональных данных.

Частые вопросы

Достаточно ли отправлять ack после записи?

Только если запись действительно закоммичена и повтор безопасен. Для внешних действий обычно нужен outbox или их собственная идемпотентность.

Можно ли добиться exactly-once?

На уровне всей распределённой бизнес-операции это сложно; чаще строят at-least-once с дедупликацией и проверяемыми эффектами.

Что делать с долгой обработкой?

Настроить heartbeat или visibility timeout, ограничить prefetch и при необходимости разбить операцию на этапы.

Когда нужна помощь специалиста

Если consumer теряет сообщения после раннего ack, я могу проверить порядок commit, настройки broker, идемпотентность и DLQ и внедрить inbox или outbox. Для оценки нужны схема обработчика, настройки очереди и один обезличенный message flow.