Cum coordonezi un cron job între mai multe noduri NestJS?

Question

IT Interview Practice · Accepted Answer

Definește mai întâi ce înseamnă „doar un nod rulează cronjobul”. **Prevenirea execuției simultane și prevenirea repetării efectului de afaceri sunt cerințe diferite.** Un planificator comun coordonează execuția; operația însăși trebuie să rămână sigură după o cădere și o reluare.

Să luăm o sarcină zilnică de facturare instalată pe trei noduri NestJS. Vrem să ruleze activitatea programată fără să genereze încă o factură când un worker repornește.

## 1. Înțelege de ce toate nodurile pornesc sarcina

Fiecare instanță a aplicației își înregistrează propriul callback cron. La ora programată, fiecare poate porni independent:

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

Un indicator local isRunning există doar într-un proces. waitForCompletion din NestJS poate preveni suprapunerea callbackurilor în acea instanță, dar nu coordonează celelalte noduri. Același indicator pe toate cele trei noduri înseamnă tot trei decizii separate. [Planificare NestJS](https://docs.nestjs.com/techniques/task-scheduling).

Avem, așadar, nevoie de un loc comun care decide ce muncă există și cine o poate procesa.

## 2. Alege modelul de coordonare

| Situație | Opțiune de evaluat | Responsabilitate rămasă |
| --- | --- | --- |
| Platforma oferă deja sarcini programate | Rulează planificarea în afara instanțelor web | Configurează suprapunerea, recuperarea și execuțiile ratate. |
| Echipa operează deja BullMQ | Job Scheduler comun și coadă dedicată | Configurează concurența comună și reluările sigure. |
| Sarcina existentă trebuie să rămână pe nodurile aplicației | Blocare sau lease comun | Gestionează corect proprietarul, expirarea și workerii învechiți. |

Pentru facturare, dacă Redis și BullMQ există deja, un planificator comun cu un ID stabil este o opțiune practică. Separă programarea de workeri, astfel încât adăugarea nodurilor web să nu creeze programări independente.

Pe o versiune BullMQ compatibilă, setează concurența globală a cozii dedicate la unu. Aceasta limitează joburile active între workeri; concurența locală unu pentru fiecare worker permite în continuare mai multor workeri să ruleze joburi diferite. [Concurență globală](https://docs.bullmq.io/guide/queues/global-concurrency).

Decide ce se întâmplă dacă munca de ieri încă rulează: aștepți, sari execuția sau combini aparițiile. Definește fusul orar și dacă zilele de afaceri ratate trebuie recuperate după indisponibilitate.

## 3. Protejează factura, nu doar jobul

Să presupunem că un worker creează factura și cade înainte să înregistreze finalizarea jobului. Recuperarea poate rula din nou jobul, deși factura există deja.

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

Folosește o cheie de afaceri stabilă, precum clientul plus perioada facturată. Pentru operațiile în baza locală, o constrângere de unicitate și o tranzacție pot lega crearea facturii de înregistrarea execuției finalizate. Reluarea găsește rezultatul existent în loc să creeze altă factură.

Pentru un furnizor extern, folosește cheia sa de idempotență când este disponibilă și reconciliază rezultatele incerte. ID-ul jobului sau păstrarea înregistrării lui nu reprezintă singure o garanție permanentă că acțiunea de afaceri nu se poate repeta. [Joburi idempotente](https://docs.bullmq.io/patterns/idempotent-jobs).

## 4. Cunoaște garanțiile și limitele unei blocări

O blocare comună trebuie obținută atomic. Folosește un token de proprietate, o expirare și reînnoire; eliberează blocarea numai dacă tokenul încă se potrivește. Altfel, un worker vechi poate elibera blocarea unuia nou.

Expirarea introduce alt caz: un worker suspendat revine după expirarea lease-ului, când un worker nou rulează deja. Scrierile critice pot necesita fencing tokens, numere crescătoare de proprietate verificate de destinație pentru a respinge workerii învechiți. Un timeout lung nu elimină acest risc.

Dacă mecanismul de coordonare este indisponibil, decide dacă sarcina așteaptă în loc să execute fără drept de proprietate. Pentru operații cu consecințe importante, aceasta este adesea alegerea mai sigură.

## 5. Verifică situațiile de eșec

Testează mai multe noduri, o cădere după crearea facturii, o pauză mai lungă decât lease-ul, pierderea conexiunii Redis și o lansare graduală. Înregistrează data de afaceri, workerul, încercarea și rezultatul pentru a distinge încercările repetate de efectele repetate.

**De reținut:** coordonează programarea → limitează execuția comună → fă acțiunea sigură la reluare → testează recuperarea. „Un job activ” nu demonstrează singur exact un efect de afaceri.

Situație	Opțiune de evaluat	Responsabilitate rămasă
Platforma oferă deja sarcini programate	Rulează planificarea în afara instanțelor web	Configurează suprapunerea, recuperarea și execuțiile ratate.
Echipa operează deja BullMQ	Job Scheduler comun și coadă dedicată	Configurează concurența comună și reluările sigure.
Sarcina existentă trebuie să rămână pe nodurile aplicației	Blocare sau lease comun	Gestionează corect proprietarul, expirarea și workerii învechiți.

1. Înțelege de ce toate nodurile pornesc sarcina

2. Alege modelul de coordonare

3. Protejează factura, nu doar jobul

4. Cunoaște garanțiile și limitele unei blocări

5. Verifică situațiile de eșec

Întrebări conexe