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 здатен зробити фонову роботу довговічною, а інженерна дисципліна — надійною господарську обіцянку.

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