NestJS и BullMQ: надежные фоновые задания в рабочей системе

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

BullMQ — система заданий на основе Redis; NestJS подключает ее через @nestjs/bullmq. Это сочетание хорошо работает для четко ограниченных единиц асинхронной работы: отправки писем, создания документов, обработки изображений, импорта и экспорта, отправки сообщений о событиях и контролируемых обращений к службам с ограниченной частотой запросов. Надежность обеспечивает вся окружающая архитектура, а не сам перенос функции за вызов queue.add().

Выносите работу за пределы HTTP-запроса с ясной целью

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

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

Применяйте транзакцию базы данных или журнал исходящих событий, если хозяйственная запись и намерение поставить задание в очередь должны сохраниться вместе. Запись заказа в базу и добавление задания в Redis — две отдельные операции; сбой между ними может привести к потере работы. Процесс, публикующий записи из такого журнала, способен повторно передать вторую запись, опираясь на надежно сохраненное состояние приложения.

Спроектируйте границу очереди и соглашение задания

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

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

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

Используйте Redis как надежную инфраструктуру очереди

Redis является частью границы надежности, а не одноразовым кэшем. Используйте поддерживаемую схему развертывания с аутентификацией, шифрованием при необходимости, доступом через частную сеть, резервными копиями или сохранением данных в соответствии с допустимыми потерями, проверенным переключением после отказа и запасом вместимости. В рекомендациях BullMQ для рабочей среды требуется maxmemory-policy=noeviction: вытеснение ключей очереди из-за нехватки памяти может разрушить предположения, на которых держится состояние заданий.

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

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

Сделайте последствия повторного выполнения безопасными

Повторная попытка безопасна лишь тогда, когда повторение задания приводит к тому же допустимому конечному состоянию. Исполнитель может завершить внешнее действие и аварийно остановиться до того, как BullMQ зафиксирует завершение, поэтому нельзя полагаться на выполнение «ровно один раз». Защищайте каждое последствие хозяйственным ключом идемпотентности, ограничением уникальности, условным переходом состояния, поддержкой повторов у поставщика или журналом выполненных действий. Перед действием проверяйте имеющееся состояние и сохраняйте свидетельства, по которым можно распознать уже выполненную операцию.

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

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

Относитесь к задержкам и отказам как к рабочим состояниям

Отложенное задание — это таймер с хозяйственными последствиями. Храните запланированный срок в записи предметной области, разрешайте действие лишь при подходящем текущем состоянии и ожидайте, что при недоступности исполнителей или Redis оно произойдет после заданного момента, а не точно в него. Для повторяющейся работы используйте современные планировщики заданий BullMQ, явно указывайте часовой пояс, предотвращайте нежелательное наложение запусков и определите, как наверстывать пропущенное после простоя.

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

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

Масштабируйте исполнителей по длительности обслуживания и возрасту очереди

BullMQ поддерживает одновременное выполнение внутри одного исполнителя и параллельную работу нескольких процессов или узлов. Увеличивайте число одновременных операций ввода-вывода лишь до тех пор, пока зависимые системы, пулы соединений, память и ограничения частоты остаются в норме. Для вычислительно тяжелой работы нужны отдельные процессы или вычислительные службы: увеличение асинхронной одновременности не создает процессорной мощности. Устанавливайте ограничения для каждой очереди и каждого клиента, если одна нагрузка может вытеснить другую.

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

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

Наблюдайте за обещанием, которое стоит за каждой очередью

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

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

Каждой очереди нужны ответственный, целевой уровень обслуживания, предположение о мощности, инструкция и учебная проверка восстановления. Сотрудники должны знать, как остановить добавление новой работы, исследовать отказ, защитить зависимую систему, развернуть исправление, безопасно повторить задание, проверить последствия и постепенно возобновить работу. Анализируйте и задания, которые «в конце концов завершились»: рост числа попыток часто показывает ухудшение раньше, чем появляются окончательные отказы.

Создайте фоновую обработку, которую команда сможет восстановить

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

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

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

• Хозяйственное обещание: наибольшее время ожидания, цель завершения, отмена, состояние для клиента и ответственный.
• Соглашение: устойчивый идентификатор операции, версия структуры, долговременные ссылки, совместимость и безопасные данные задания.
• Доставка: транзакционный журнал исходящих событий при необходимости, устранение повторов, безопасные повторные последствия и условные переходы.
• Отказ: типизированные ошибки, ограниченное экспоненциальное увеличение задержки со случайным отклонением, окончательная обработка, срок хранения и безопасное повторное выполнение.
• Мощность: измеренное время обслуживания, устойчивая скорость поступления, пределы зависимых систем, возраст накопившейся очереди и запас.
• Эксплуатация: показатели, трассировки, оповещения, инструкция, средства остановки и постепенного опустошения очереди, проверка восстановления и назначенный ответственный.