Сообщение становится невидимым сразу после выдачи потребителю, но обработчик может упасть до подтверждения. Как вернуть такое сообщение в обработку без ручного вмешательства?
Используют временную невидимость сообщения — visibility timeout, также называемую арендой или дедлайном подтверждения. После выдачи сообщение скрывается на ограниченный срок; если обработчик не подтвердил успешную обработку до его окончания, оно снова становится доступным. Поэтому такая схема обычно дает семантику at-least-once: сообщение может быть доставлено повторно, и обработчик должен быть идемпотентным.
Очереди должны переживать падение потребителя после получения сообщения. Если удалять сообщение сразу, сбой между получением и подтверждением приводит к потере работы; если хранить его навсегда недоступным, оно не вернется в обработку.
Временная невидимость стала компромиссом между этими рисками. Очередь временно считает сообщение занятым, но сохраняет возможность повторной доставки, если потребитель не докажет успешное завершение обработки.
Пусть обработчик получил сообщение, выполнил часть работы и завершился из-за сбоя до подтверждения. Очередь не может надежно отличить такой сбой от долгой обработки или временной потери связи с потребителем.
Слишком короткий тайм-аут вызовет повторную доставку еще работающего сообщения. Слишком длинный увеличит задержку восстановления после падения. Повторная обработка может повторно списать деньги, создать дубликат записи или отправить уведомление дважды, если бизнес-операция не защищена от повторов.
При выдаче сообщения очередь устанавливает ему срок невидимости. В течение этого срока другие потребители обычно не получают сообщение, но оно не считается окончательно завершенным. После успешной обработки потребитель отправляет подтверждение, и очередь удаляет сообщение или помечает его завершенным.
Если подтверждение не поступило до истечения срока, сообщение снова становится доступным. Причиной может быть падение процесса, потеря сети, превышение времени обработки или отклоненное подтверждение. Повторная доставка является нормальным сценарием, а не исключением.
Тайм-аут выбирают больше обычного времени обработки, но не настолько большим, чтобы отказ потребителя надолго блокировал сообщение. Для длительных операций применяют продление дедлайна небольшими периодами, однако продление не должно скрывать зависший обработчик бесконечно.
Подтверждение должно означать именно завершение требуемой бизнес-операции. Если сначала подтвердить сообщение, а затем выполнить операцию, сбой между этими действиями может привести к потере работы. Если сначала выполнить операцию, а затем подтвердить, возможен повтор; поэтому нужны идемпотентность, дедупликация по идентификатору операции или транзакционная связь между изменением состояния и фиксацией результата.
Этот механизм не гарантирует порядок сообщений, однократное выполнение или отсутствие дублей. Он решает более узкую задачу: автоматическое возвращение неподтвержденной доставки после сбоя или превышения дедлайна.
Сервис обрабатывает платежные события около десяти секунд, но иногда внешний провайдер отвечает до минуты. При тайм-ауте в пятнадцать секунд сообщения начинают повторно выдаваться другим потребителям. Это создает конкурентную обработку одного платежа и увеличивает риск дублей.
Вариант с увеличением тайм-аута до нескольких минут уменьшает число ложных повторов, но замедляет восстановление очереди после падения и дольше удерживает сообщения за недоступным потребителем. Вариант с немедленным удалением сообщения быстрее очищает очередь, но допускает потерю платежного события при сбое после получения.
Выбранное решение — базовый дедлайн, периодическое продление для живой обработки, идемпотентный ключ платежной операции и отдельная обработка сообщений, которые многократно не подтверждаются. В результате сбой приводит к повторной попытке, а повтор не создает второе списание; при этом действительно зависшие сообщения не блокируются навсегда.
Нет. Даже длинный тайм-аут не устраняет повторы из-за сетевого сбоя, потери подтверждения, повторной доставки после восстановления очереди или неопределенного результата операции. Тайм-аут уменьшает вероятность преждевременного повтора, но обработчик все равно должен корректно работать при повторной доставке.
Сообщение может оставаться невидимым неопределенно долго, если продление не ограничено. Поэтому продление следует связывать с признаками живой обработки, ограничивать максимальным временем и дополнять мониторингом возраста сообщений, длительности обработки и числа продлений. Иначе механизм восстановления после сбоя превращается в способ скрыть зависшие задачи.
Только если конкретная архитектура предоставляет такую атомарность между хранилищем результата и очередью. В общем случае это две разные системы, поэтому сбой между записью результата и подтверждением вызывает повтор, а сбой в обратном порядке может вызвать потерю сообщения. Практический безопасный вариант — сначала надежно зафиксировать идемпотентный результат, затем подтверждать сообщение; повторная доставка обнаружит уже обработанный идентификатор и завершится без повторного эффекта.