Jak koordynować zadanie cron na wielu węzłach NestJS?

Question

IT Interview Practice · Accepted Answer

Najpierw określ znaczenie „cronjob działa tylko na jednym węźle”. **Zapobieganie równoczesnemu wykonaniu i powtórzeniu skutku biznesowego to różne wymagania.** Wspólny harmonogram koordynuje wykonanie; sama operacja musi być bezpieczna po awarii i ponowieniu.

Rozważ codzienne fakturowanie na trzech węzłach NestJS. Zadanie ma się wykonać, ale restart workera nie może tworzyć kolejnej faktury.

## 1. Zrozum, dlaczego startują wszystkie węzły

Każda instancja rejestruje własny callback crona. O zaplanowanej godzinie każda może wystartować niezależnie:

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

Lokalna flaga isRunning istnieje tylko w jednym procesie. NestJS waitForCompletion zapobiega nakładaniu callbacków tej instancji, ale nie koordynuje innych węzłów. Ta sama flaga na trzech węzłach nadal oznacza trzy niezależne decyzje. [Harmonogram NestJS](https://docs.nestjs.com/techniques/task-scheduling).

Potrzebne jest więc wspólne miejsce określające, jakie zadania istnieją i kto może je przetwarzać.

## 2. Wybierz model koordynacji

| Sytuacja | Opcja do oceny | Pozostała odpowiedzialność |
| --- | --- | --- |
| Platforma już zapewnia zadania okresowe | Planuj poza instancjami webowymi | Skonfiguruj nakładanie, odzyskiwanie i pominięte uruchomienia. |
| Zespół już utrzymuje BullMQ | Wspólny Job Scheduler i dedykowana kolejka | Ustal globalną współbieżność i bezpieczne ponowienia. |
| Zadanie musi zostać na węzłach aplikacji | Wspólna blokada lub dzierżawa | Poprawnie obsłuż właściciela, wygaśnięcie i nieaktualne workery. |

Jeśli Redis i BullMQ już działają, wspólny harmonogram ze stabilnym ID jest praktycznym kandydatem dla faktur. Oddziel planowanie od workerów, aby dodawanie węzłów webowych nie tworzyło niezależnych harmonogramów.

W obsługiwanej wersji BullMQ ustaw globalną współbieżność dedykowanej kolejki na jeden. Ogranicza to aktywne zadania wszystkich workerów; lokalna wartość jeden nadal pozwala wielu workerom wykonywać różne zadania równocześnie. [Globalna współbieżność](https://docs.bullmq.io/guide/queues/global-concurrency).

Ustal, co zrobić, gdy wczorajsze zadanie nadal działa: czekać, pominąć czy połączyć wystąpienia. Określ strefę czasową oraz nadrabianie pominiętych dat biznesowych po przestoju.

## 3. Chroń fakturę, nie tylko zadanie

Załóżmy, że worker tworzy fakturę i pada przed zapisaniem zakończenia zadania. Odzyskiwanie może wykonać zadanie ponownie, choć faktura istnieje.

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

Użyj stabilnego klucza biznesowego, na przykład klienta i okresu rozliczeniowego. W lokalnej bazie ograniczenie unikalności i transakcja mogą połączyć utworzenie faktury z zapisem zakończonego wykonania. Ponowienie odnajdzie istniejący wynik zamiast tworzyć następną fakturę.

U zewnętrznego dostawcy używaj klucza idempotencji, jeśli jest obsługiwany, i uzgadniaj niepewne wyniki. Sam identyfikator zadania lub zachowany rekord kolejki nie jest trwałą gwarancją, że czynność biznesowa nigdy się nie powtórzy. [Zadania idempotentne](https://docs.bullmq.io/patterns/idempotent-jobs).

## 4. Poznaj granice gwarancji blokady

Wspólną blokadę trzeba zdobywać atomowo. Używaj tokenu właściciela, terminu ważności i odnawiania; zwalniaj tylko przy nadal zgodnym tokenie. Inaczej stary worker może zwolnić blokadę nowego.

Wygaśnięcie tworzy kolejny przypadek: zatrzymany worker wraca po końcu dzierżawy, gdy nowy już pracuje. Krytyczne zapisy mogą potrzebować fencing tokens, czyli rosnących numerów własności sprawdzanych przez odbiorcę w celu odrzucenia starego workera. Sam długi timeout nie eliminuje ryzyka.

Jeśli koordynacja jest niedostępna, zdecyduj, czy zadanie ma czekać zamiast działać bez własności. Przy istotnych skutkach jest to często bezpieczniejsze.

## 5. Zweryfikuj awarie

Testuj wiele węzłów, awarię po utworzeniu faktury, pauzę dłuższą od dzierżawy, utratę połączenia z Redis i stopniowe wdrożenie. Rejestruj datę biznesową, workera, próbę i wynik, aby odróżnić powtórzone próby od powtórzonych skutków.

**Zapamiętaj:** koordynuj harmonogram → ogranicz wspólne wykonanie → zapewnij bezpieczne ponowienia biznesowe → testuj odzyskiwanie. „Jedno aktywne zadanie” nie dowodzi dokładnie jednego skutku biznesowego.

Sytuacja	Opcja do oceny	Pozostała odpowiedzialność
Platforma już zapewnia zadania okresowe	Planuj poza instancjami webowymi	Skonfiguruj nakładanie, odzyskiwanie i pominięte uruchomienia.
Zespół już utrzymuje BullMQ	Wspólny Job Scheduler i dedykowana kolejka	Ustal globalną współbieżność i bezpieczne ponowienia.
Zadanie musi zostać na węzłach aplikacji	Wspólna blokada lub dzierżawa	Poprawnie obsłuż właściciela, wygaśnięcie i nieaktualne workery.

1. Zrozum, dlaczego startują wszystkie węzły

2. Wybierz model koordynacji

3. Chroń fakturę, nie tylko zadanie

4. Poznaj granice gwarancji blokady

5. Zweryfikuj awarie

Powiązane pytania