Как координировать cron-задачу на нескольких узлах NestJS?

Question

IT Interview Practice · Accepted Answer

Сначала определите, что означает «cronjob запускает только один узел». **Предотвращение одновременного выполнения и предотвращение повторного бизнес-эффекта — разные требования.** Общий планировщик координирует выполнение, а сама операция должна оставаться безопасной после сбоя и повтора.

Рассмотрим ежедневную задачу выставления счетов на трёх узлах NestJS. Нужно выполнить работу по расписанию, не создавая ещё один счёт при перезапуске worker.

## 1. Поймите, почему задачу запускают все узлы

Каждый экземпляр приложения регистрирует собственный cron callback. В назначенное время каждый может стартовать независимо:

```text
00:00 -> Node A -> invoice task
      -> Node B -> invoice task
      -> Node C -> invoice task
```

Локальный флаг isRunning существует лишь в одном процессе. NestJS waitForCompletion предотвращает пересечение callback в этом экземпляре, но не координирует другие узлы. Одинаковый флаг на трёх узлах всё равно оставляет три независимых решения. [Планирование NestJS](https://docs.nestjs.com/techniques/task-scheduling).

Значит, нужен общий механизм, определяющий существующую работу и право на её обработку.

## 2. Выберите модель координации

| Ситуация | Вариант для оценки | Оставшаяся ответственность |
| --- | --- | --- |
| Платформа уже предоставляет задачи по расписанию | Вынести планирование из веб-экземпляров | Настроить пересечения, восстановление и пропущенные запуски. |
| Команда уже использует BullMQ | Общий Job Scheduler и выделенная очередь | Настроить общую конкурентность и безопасные повторы. |
| Задача должна остаться на узлах приложения | Общая блокировка или аренда | Корректно обрабатывать владельца, истечение и устаревших worker. |

Для счетов, если Redis и BullMQ уже есть, практичен общий планировщик со стабильным ID. Отделите расписание от worker, чтобы добавление веб-узлов не создавало независимые расписания.

На поддерживаемой версии BullMQ установите глобальную конкурентность выделенной очереди в единицу. Это ограничит активные задания между worker; локальная единица на каждом worker по-прежнему допускает выполнение разных заданий несколькими worker. [Глобальная конкурентность](https://docs.bullmq.io/guide/queues/global-concurrency).

Решите, что делать, если вчерашняя работа ещё выполняется: ждать, пропустить или объединить запуски. Определите часовой пояс и необходимость наверстать пропущенные бизнес-даты после простоя.

## 3. Защищайте счёт, а не только задание

Допустим, worker создал счёт и упал до фиксации завершения задания. Восстановление может запустить задачу снова, хотя счёт уже существует.

```text
[Create invoice] -> [Crash before completion]
                              |
                            [Retry]
                              |
                  [Same business key: reuse result]
```

Используйте стабильный бизнес-ключ, например клиент плюс расчётный период. Для работы в локальной базе ограничение уникальности и транзакция могут связать создание счёта с записью завершённого запуска. Тогда повтор найдёт существующий результат вместо создания второго счёта.

Для внешнего поставщика используйте его ключ идемпотентности, если поддерживается, и сверяйте неопределённые результаты. Сам по себе ID задания или сохранённая запись о нём не гарантирует навсегда, что бизнес-действие не повторится. [Идемпотентные задания](https://docs.bullmq.io/patterns/idempotent-jobs).

## 4. Понимайте возможности и ограничения блокировки

Общую блокировку нужно получать атомарно. Используйте токен владельца, срок действия и продление; освобождайте её, только если токен всё ещё совпадает. Иначе старый worker может снять блокировку нового.

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

При недоступной координации определите, должна ли задача ждать вместо запуска без владения. Для действий с важными последствиями это часто безопаснее.

## 5. Проверьте сценарии сбоев

Проверьте несколько узлов, сбой после создания счёта, паузу длиннее аренды, потерю связи с Redis и поэтапное развёртывание. Записывайте бизнес-дату, worker, попытку и результат, чтобы отличать повторные попытки от повторных эффектов.

**Запомните:** согласовать расписание → ограничить общее выполнение → обеспечить безопасные повторы бизнес-действия → проверить восстановление. «Одно активное задание» само по себе не доказывает ровно один бизнес-эффект.

Ситуация	Вариант для оценки	Оставшаяся ответственность
Платформа уже предоставляет задачи по расписанию	Вынести планирование из веб-экземпляров	Настроить пересечения, восстановление и пропущенные запуски.
Команда уже использует BullMQ	Общий Job Scheduler и выделенная очередь	Настроить общую конкурентность и безопасные повторы.
Задача должна остаться на узлах приложения	Общая блокировка или аренда	Корректно обрабатывать владельца, истечение и устаревших worker.

1. Поймите, почему задачу запускают все узлы

2. Выберите модель координации

3. Защищайте счёт, а не только задание

4. Понимайте возможности и ограничения блокировки

5. Проверьте сценарии сбоев

Похожие вопросы