Фоновая обработка и сообщения¶
Требования применяются к worker-, job- и consumer-процессам. Уровни
обязательности определены в корневом README.md.
BE-JOB-001. Подтверждение после результата¶
Уровень: MUST
Применяется к: сообщению с явным подтверждением обработки
Consumer должен подтверждать сообщение только после фиксации всех обязательных эффектов. При timeout, отмене, crash или технической ошибке до фиксации сообщение не должно подтверждаться и должно оставаться доступным для повторной доставки.
Обоснование¶
Преждевременное подтверждение создаёт незаметную потерю работы.
Проверка¶
- integration-тест crash до и после фиксации;
- тест недоступности хранилища и broker;
- сопоставление подтверждения с транзакционной границей.
Исключения¶
At-most-once обработка допустима только по явному бизнес-контракту через ADR.
BE-JOB-002. Идемпотентная повторная обработка¶
Уровень: MUST
Применяется к: сообщению, допускающему повторную доставку
Обработчик должен использовать стабильный идентификатор сообщения или операции и предотвращать повторный необратимый эффект. Проверка дубликата и фиксация защищаемого результата должны быть атомарны либо согласованы транзакционным контрактом.
Идемпотентность не должна основываться только на локальной памяти экземпляра.
Обоснование¶
Повторная доставка является штатным сценарием и не должна дублировать эффект.
Проверка¶
- последовательная и конкурентная повторная доставка;
- тест restart между эффектом и подтверждением;
- проверка атомарности deduplication.
Исключения¶
Не допускаются для необратимого эффекта при at-least-once доставке.
BE-JOB-003. Ограниченные повторы и терминальный результат¶
Уровень: MUST
Применяется к: неуспешной обработке сообщения
Временная ошибка должна повторяться конечное число раз с backoff и jitter. Постоянная ошибка, исчерпавшее повторы или невалидное сообщение должны получать явно определённый и наблюдаемый терминальный результат. Такое сообщение не должно создавать бесконечный цикл доставки или считаться успешно выполненной обязательной работой.
Для сообщения, которое может быть исправлено, расследовано или повторно
обработано, следует использовать dead-letter channel либо эквивалентное
изолированное хранилище с управляемым replay по INT-EVT-009. Эту возможность
MAY предоставлять broker или платформа, а не микросервис.
Обоснование¶
Poison message не должно блокировать очередь или создавать бесконечный цикл.
Проверка¶
- тест временной и постоянной ошибки;
- тест достижения лимита и наблюдаемого терминального результата;
- при наличии изоляции — тест записи и контролируемого replay.
Исключения¶
DLQ MAY отсутствовать без ADR, если терминальный результат определён, наблюдаем и не маскирует потерю обязательной работы.
BE-JOB-004. Порядок и конкурентность¶
Уровень: MUST
Применяется к: параллельной обработке сообщений
Контракт должен явно определить, требуется ли порядок и на каком ключе. Если порядок не гарантирован инфраструктурой, обработчик не должен зависеть от порядка доставки. Конкурентность, prefetch и размер локальной очереди должны иметь конечные конфигурируемые пределы.
Обоснование¶
Неявное предположение о порядке и неограниченный prefetch приводят к гонкам и потере управляемости при перегрузке.
Проверка¶
- тест перестановки и параллельной доставки;
- тест двух сообщений одного ключа;
- нагрузочный тест лимитов prefetch и очереди.
Исключения¶
Последовательная обработка допустима как явно зафиксированная модель.
BE-JOB-005. Срок актуальности работы¶
Уровень: MUST
Применяется к: job или сообщению, результат которого после определённого момента теряет смысл либо становится небезопасным
Контракт должен определять момент создания, допустимое время ожидания и проверяемое условие истечения работы. Consumer должен проверять актуальность до начала обязательного эффекта и повторно после ожидания, способного превысить срок.
Истёкшая работа не должна выполнять устаревший бизнес-эффект. Она должна завершаться отдельным стабильным исходом, подтверждаться либо изолироваться по объявленному контракту и отражаться в метрике. Истечение не должно интерпретироваться как успешный результат операции.
Обоснование¶
Очередь может восстановиться после длительного backlog и доставить действие, которое уже отменено, заменено или нарушает актуальное временное ограничение.
Проверка¶
- тест доставки до и после срока актуальности;
- тест истечения во время ожидания зависимости;
- проверка отсутствия бизнес-эффекта и отдельной метрики истечения;
- тест согласованности времени producer и consumer.
Исключения¶
Работа, которую контракт требует выполнить независимо от возраста, не имеет
срока истечения, но остаётся ограниченной retention и операционными пределами
по INT-EVT-012.
BE-JOB-006. Владение зарезервированной работой¶
Уровень: MUST
Применяется к: обработке, для которой broker или scheduler выдаёт ограниченную по времени reservation, visibility timeout или lease
Максимальная длительность обработки должна укладываться в срок reservation либо consumer должен продлевать его до истечения через ограниченную timeout операцию. Потеря reservation или отказ продления должны прекращать начало новых эффектов этой обработки и не должны приводить к подтверждению сообщения.
Если уже начатый эффект нельзя отменить, его фиксация должна защищаться идемпотентностью, версией или fencing-механизмом, который отклоняет прежнего владельца. Локальное убеждение consumer о владении после истечения reservation не является подтверждением владения.
Обоснование¶
После паузы процесса или сетевого разделения broker может передать работу другому consumer, пока прежний экземпляр продолжает выполнять эффект.
Проверка¶
- fault-injection тест паузы дольше reservation;
- тест отказа и задержки продления;
- конкурентный тест прежнего и нового владельца;
- проверка отсутствия подтверждения после потери владения.
Исключения¶
Требование к продлению не применяется, если reservation гарантированно превышает ограниченную максимальную длительность обработки с проверяемым резервом.
BE-JOB-007. Независимый результат элементов batch¶
Уровень: MUST
Применяется к: получению или обработке нескольких независимо подтверждаемых сообщений одним batch
Consumer должен сохранять результат каждого элемента batch отдельно. Ошибка одного элемента не должна приводить к подтверждению неуспешного элемента, потере остальных либо повторному необратимому эффекту уже успешно зафиксированных элементов.
Если transport поддерживает только общее подтверждение batch, обработчик
должен быть идемпотентным для всего повторяемого набора либо сначала фиксировать
индивидуальные результаты в устойчивом состоянии. Poison message должно
изолироваться по BE-JOB-003, не блокируя бессрочно остальные элементы.
Обоснование¶
Общий исход batch превращает единичный отказ либо в потерю сообщения, либо в повтор всех уже выполненных эффектов.
Проверка¶
- тест отказа первого, среднего и последнего элемента;
- тест crash после частичной фиксации batch;
- повторная доставка всего batch;
- проверка индивидуальных подтверждений или устойчивых результатов.
Исключения¶
Атомарный batch с единым бизнес-результатом находится вне области требования к независимым элементам и должен иметь общий транзакционный контракт.