{
  "index": 276,
  "slug": "editorial-2020-05-practice-background-jobs",
  "title": "Фоновые задачи без потерь: запись намерения, повтор и результат",
  "excerpt": "Как вынести долгую операцию из HTTP-запроса и не потерять её между базой, брокером и worker: состояние задачи, outbox, идемпотентность, ack и карантин.",
  "contentHtml": "<p>Пользователь запускает экспорт и получает <code>202 Accepted</code>. Через десять минут файла нет. В журнале виден входящий запрос, но непонятно, создали ли задачу, отправили ли сообщение и дошёл ли worker до записи результата. В другом варианте файл уже создан, worker падает до <code>ack</code>, а повторная доставка создаёт второй файл или повторно отправляет письмо. Ошибка стоит дорого: поддержка не может назвать состояние операции, разработчик не отличает потерю сообщения от дубля, а клиент повторяет опасный запрос.</p>\n<p>Тезис простой: очередь не хранит бизнес-результат. Она переносит delivery от publisher к consumer. Смысл операции должен жить в записи приложения с устойчивым <code>jobId</code>. HTTP фиксирует намерение, dispatcher публикует сообщение, worker выполняет работу, сохраняет результат и только потом подтверждает delivery. После этого повтор считается обычной веткой, а не аварией, которую можно исключить настройкой.</p>\n<h2>Механизм: четыре разных факта</h2>\n<p>У фоновой операции есть несколько границ. Запись задачи означает, что система приняла намерение. Запись outbox означает, что публикацию можно возобновить после перезапуска. Delivery означает, что брокер передал сообщение конкретному consumer. Сохранённый результат означает, что бизнес-действие завершилось. <code>ack</code> подтверждает только конкретное delivery. Он не доказывает, что файл существует, письмо ушло или строка в базе обновилась.</p>\n<p>У каждой записи должен быть один идентификатор операции. В учебном примере это <code>export-42</code>. В строке задачи удобно хранить <code>state</code>, <code>attempt</code>, входной тип, ключ результата и последнюю безопасную для журнала ошибку. Секреты и полный payload в журнал не попадают. Пользователь получает <code>jobId</code>, а затем читает статус по нему. Ответ «принято» не должен маскироваться под «готово».</p>\n<div class='table-scroll'><table><caption>Симптом → причина → проверка → действие</caption><thead><tr><th scope='col'>Симптом</th><th scope='col'>Причина</th><th scope='col'>Проверка</th><th scope='col'>Действие</th></tr></thead><tbody><tr><td>Есть <code>queued</code>, но нет delivery</td><td>Dispatcher не прочитал outbox или не получил подтверждение publisher</td><td>Найти outbox по <code>jobId</code>, проверить <code>publishedAt</code> и ошибку отправки</td><td>Повторить публикацию; не создавать новую задачу</td></tr><tr><td>Одно сообщение приходит несколько раз</td><td>Процесс упал после результата и до <code>ack</code> либо соединение закрылось</td><td>Сравнить <code>attempt</code>, <code>state</code> и ключ результата</td><td>Вернуть сохранённый результат и подтвердить повтор; повторить работу только при отсутствии результата</td></tr><tr><td>Очередь быстро растёт</td><td>Worker медленнее входящего потока или удерживает слишком много delivery</td><td>Сопоставить время обработки, backlog, prefetch и число активных worker</td><td>Ограничить параллелизм, добавить worker или принять backpressure</td></tr><tr><td>Одна задача бесконечно возвращается</td><td>Невалидный payload или постоянная ошибка зависимости</td><td>Посчитать попытки и сгруппировать <code>lastErrorCode</code></td><td>Ограничить retry и направить сообщение в карантин</td></tr><tr><td>Задача в <code>succeeded</code>, но результата нет</td><td>Состояние записали раньше внешнего эффекта или ключ результата не проверяется</td><td>Проверить объект по стабильному ключу и порядок транзакций</td><td>Не ставить успех до durable result; добавить восстановление или ручной разбор</td></tr></tbody></table></div>\n<figure><img src='/assets/editorial/2020/background-job-lifecycle-2020.svg' alt='Жизненный цикл фоновой задачи: HTTP сохраняет задачу и outbox, dispatcher публикует сообщение, worker сохраняет результат, затем отправляет ack; ошибка уходит в повтор или карантин.' loading='lazy' /><figcaption>У операции есть отдельные границы: запись намерения, публикация, delivery, результат и подтверждение. Схема показывает, где искать потерю и почему <code>ack</code> стоит после результата.</figcaption></figure>\n<h2>Запись и публикация</h2>\n<p>Наивная последовательность выглядит так: сначала вставить задачу в базу, затем отправить сообщение. Сбой между двумя действиями оставляет строку <code>queued</code> без delivery. Обратный порядок создаёт другую дыру: worker получает сообщение, пока транзакция с задачей ещё не зафиксирована. Распределённая транзакция между базой и брокером решает не каждый сценарий и усложняет маленький сервис.</p>\n<p>Практичный компромисс — сохранить задачу и outbox в одной транзакции приложения. Отдельный dispatcher выбирает outbox без отметки публикации. Он отправляет короткое сообщение <code>{ jobId, type, version }</code> и ставит <code>publishedAt</code> только после подтверждения выбранного клиента брокера. Если dispatcher умер после отправки, но до отметки, он отправит сообщение снова. Поэтому consumer обязан выдерживать duplicate. Уникальность результата обеспечит не брокер, а контракт бизнес-операции.</p>\n<pre><code>// Учебный псевдокод. Это не готовый клиент брокера.\nasync function requestExport(input, db) {\n  const jobId = `export-${input.accountId}-${input.period}`;\n\n  await db.transaction(async (tx) =&gt; {\n    await tx.insertJob({\n      id: jobId,\n      type: 'report.export',\n      state: 'queued',\n      attempt: 0,\n      resultKey: null\n    });\n    await tx.insertOutbox({\n      type: 'report.export.requested',\n      jobId,\n      version: 1,\n      publishedAt: null\n    });\n  });\n\n  return { accepted: true, jobId };\n}</code></pre>\n<p>Здесь <code>jobId</code> намеренно стабилен для выбранного набора входных данных. Реальный проект должен решить, допустимы ли два экспорта одного периода. Если допустимы, идентификатор включает уникальный request key. Если нет, уникальный индекс или условная вставка должны остановить второй запуск. Нельзя получить идемпотентность только из названия очереди.</p>\n<h2>Worker и порядок ack</h2>\n<p>Worker читает запись задачи по <code>jobId</code>, а не доверяет payload как единственному источнику состояния. Он проверяет финальные состояния. Для <code>succeeded</code> достаточно подтвердить повторное delivery. Для <code>quarantined</code> нужно подтвердить delivery и оставить причину доступной оператору. Для активной задачи worker выполняет действие с устойчивым ключом результата.</p>\n<p>Безопасный порядок для учебного экспорта такой: взять задачу, пометить попытку, создать файл по ключу <code>reports/export-42.csv</code>, проверить, что запись устойчива, перевести задачу в <code>succeeded</code>, отправить <code>ack</code>. Сбой после сохранения файла и до <code>ack</code> вызовет повтор. Повтор увидит существующий ключ, не создаст второй файл и подтвердит новое delivery. Сбой до сохранения результата оставит задачу для повторной попытки.</p>\n<pre><code>// Учебный обработчик. API jobs и broker абстрактен.\nasync function handleDelivery(delivery, jobs, broker) {\n  const job = await jobs.findForUpdate(delivery.jobId);\n\n  if (job.state === 'succeeded' || job.state === 'quarantined') {\n    await broker.ack(delivery.tag);\n    return;\n  }\n\n  try {\n    await jobs.markRunning(job.id, delivery.attempt);\n    const resultKey = `reports/${job.id}.csv`;\n    await writeReportOnce(resultKey, job.payload);\n    await jobs.markSucceeded(job.id, resultKey);\n    await broker.ack(delivery.tag);\n  } catch (error) {\n    const nextAttempt = delivery.attempt + 1;\n    await jobs.markRetryOrQuarantine(job.id, nextAttempt, error.code);\n    await broker.nack(delivery.tag, { requeue: nextAttempt &lt; 3 });\n  }\n}</code></pre>\n<p>Функция <code>writeReportOnce</code> здесь обозначает контракт, а не готовую библиотеку. Она может использовать уникальный ключ объекта, условную вставку или идемпотентный endpoint внешнего сервиса. Если внешний сервис не поддерживает повтор безопасно, состояние задачи не может в одиночку отменить уже отправленное письмо или платёж. Для такого эффекта нужен ключ идемпотентности на внешней стороне либо отдельный статусный протокол.</p>\n<h2>Повтор, backpressure и карантин</h2>\n<p>Повтор подходит для временной ошибки: короткого сетевого сбоя, временной недоступности зависимости или превышения лимита. Он не исправляет неверную схему сообщения. Для постоянной ошибки нужен предел попыток, задержка между ними и отдельная очередь карантина. Иначе poison message снова попадает в начало очереди, worker тратит время на одну и ту же ошибку, а полезные задачи ждут.</p>\n<p>Не ставьте минимальную задержку без причины. Три мгновенных повтора могут усилить аварию зависимости. Для временной ошибки задайте ограниченное число попыток и возрастающую задержку. Для ошибки валидации отправляйте задачу сразу в карантин. В записи сохраняйте код причины и номер последней попытки, но не полный ответ внешней системы с персональными данными.</p>\n<p>Очередь не заменяет ограничение нагрузки. Если worker получает новые delivery быстрее, чем завершает старые, растут backlog и память. Ограничение prefetch уменьшает число незавершённых delivery на consumer, но не ускоряет обработку. Если одна задача блокирует worker надолго, отделите её очередь или задайте лимит времени. Таймаут должен переводить задачу в понятное состояние, а не просто обрывать функцию без записи.</p>\n<h2>Порядок внедрения</h2>\n<ol><li>Назовите одну операцию и её границу. Запишите, что пользователь считает «принято», «выполнено» и «отклонено».</li><li>Создайте модель задачи с устойчивым <code>jobId</code>, состоянием, попыткой, ключом результата и безопасной причиной ошибки.</li><li>Сохраните задачу и outbox в одной транзакции. Верните клиенту <code>202</code> и <code>jobId</code>, а не обещание готового результата.</li><li>Настройте dispatcher, который повторяет неопубликованный outbox и отмечает публикацию только после подтверждения клиента брокера.</li><li>Сделайте worker идемпотентным по <code>jobId</code> или ключу результата. Сначала сохраните бизнес-результат и состояние, затем отправьте <code>ack</code>.</li><li>Разделите временные и постоянные ошибки. Для временных задайте лимит и задержку, для постоянных — карантин с причиной.</li><li>Добавьте статусные поля и журнал переходов: received, running, retry, succeeded, quarantined. Не записывайте секреты и лишний payload.</li><li>Проверьте четыре сбоя отдельно: падение до публикации, после публикации, после результата до ack и на третьей неудачной попытке.</li></ol>\n<h2>Ограничения</h2>\n<p>Эта схема не даёт exactly-once. Она даёт повторяемость и место, где проверить результат. Между сохранением результата и <code>ack</code> всегда остаётся окно, поэтому бизнес-действие должно выдерживать duplicate. Outbox не делает публикацию атомарной с брокером. Publisher confirm подтверждает взаимодействие publisher с узлом брокера, а не обработку сообщения worker.</p>\n<p>Пример не содержит настоящего подключения к RabbitMQ, настройки очереди, TLS, прав, транзакций конкретной СУБД или измеренных значений latency. Имена <code>export-42</code>, ключ файла и число попыток — учебные данные. Их нельзя выдавать за результат нагрузочного теста. В реальной системе отдельно проверяют срок хранения outbox, рост карантина, восстановление после рестарта, размер payload, таймаут внешнего API и удаление чувствительных данных.</p>\n<p>Если действие необратимо, например платёж или отправка письма, запись результата после вызова может не решить двойное выполнение. Нужен idempotency key, который принимает внешний сервис, или промежуточный статус с ручным подтверждением. Если контракт отсутствует, безопаснее остановить автоматический retry и передать операцию в разбор, чем обещать автоматическую надёжность.</p>\n<h2>Критерий готовности</h2>\n<p>Решение готово, когда по одному <code>jobId</code> можно определить: записано ли намерение, опубликован ли outbox, сколько было delivery, какой результат сохранён и почему задача остановилась. Тестовый повтор после сбоя между результатом и <code>ack</code> не создаёт второй результат. Невалидная задача после заданного числа попыток попадает в карантин. Сбой dispatcher не теряет outbox. Эти проверки должны видеть состояние базы, сообщения и результат, а не только код ответа HTTP.</p>\n<h2>Проверяемые источники</h2><ul><li><a href='https://www.rabbitmq.com/docs/confirms' target='_blank' rel='noopener noreferrer'>RabbitMQ: Consumer Acknowledgements and Publisher Confirms</a> — официальное описание различий между consumer acknowledgement и publisher confirm, области delivery tag, ручного <code>ack</code>, <code>nack</code> и requeue.</li><li><a href='https://www.rabbitmq.com/docs/dlx' target='_blank' rel='noopener noreferrer'>RabbitMQ: Dead Letter Exchanges</a> — официальное описание маршрутизации отклонённых сообщений и условий dead-lettering; конкретные политики хранения и маршруты задаёт приложение.</li><li><a href='https://www.rabbitmq.com/docs/reliability' target='_blank' rel='noopener noreferrer'>RabbitMQ: Reliability Guide</a> — официальные рекомендации по надёжности соединений, публикации и обработке; документ не заменяет проверку выбранного клиента и стенда.</li></ul>"
}