Come coordinare un cron su più nodi NestJS?

Question

IT Interview Practice · Accepted Answer

Definisci prima cosa significa “un solo nodo esegue il cronjob”. **Impedire esecuzioni simultanee e impedire un effetto aziendale ripetuto sono requisiti diversi.** Uno scheduler condiviso coordina l'esecuzione; l'operazione deve restare sicura dopo un arresto anomalo e un nuovo tentativo.

Considera un job giornaliero di fatturazione distribuito su tre nodi NestJS. Vogliamo eseguire il lavoro previsto senza generare un'altra fattura quando un worker riparte.

## 1. Comprendi perché tutti i nodi avviano il task

Ogni istanza dell'applicazione registra il proprio callback cron. All'orario previsto, ciascuna può partire autonomamente:

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

Un flag isRunning locale esiste soltanto in un processo. waitForCompletion di NestJS può evitare callback sovrapposti su quell'istanza, ma non coordina gli altri nodi. Aggiungere lo stesso flag a tutti e tre lascia comunque tre decisioni separate. [Scheduling NestJS](https://docs.nestjs.com/techniques/task-scheduling).

Serve quindi un punto condiviso che stabilisca quale lavoro esiste e chi può elaborarlo.

## 2. Scegli il modello di coordinamento

| Situazione | Opzione da valutare | Responsabilità che rimane |
| --- | --- | --- |
| La piattaforma offre già job pianificati | Spostare la pianificazione fuori dalle istanze web | Configurare sovrapposizioni, recupero ed esecuzioni saltate. |
| Il team gestisce già BullMQ | Job Scheduler condiviso e coda dedicata | Configurare concorrenza condivisa e tentativi sicuri. |
| Il task deve restare sui nodi applicativi | Lock o lease condiviso | Gestire correttamente proprietà, scadenza e worker obsoleti. |

Per la fatturazione, se Redis e BullMQ sono già presenti, uno scheduler condiviso con ID stabile è una scelta pratica da valutare. Separa la pianificazione dai worker, così l'aggiunta di nodi web non crea pianificazioni indipendenti.

Su una versione BullMQ che lo supporta, imposta a uno la concorrenza globale della coda dedicata. Questo limita i job attivi tra tutti i worker; una concorrenza locale di uno su ciascun worker permette ancora a più worker di eseguire job diversi. [Concorrenza globale](https://docs.bullmq.io/guide/queues/global-concurrency).

Decidi cosa fare se il lavoro di ieri è ancora in corso: attendere, saltare o combinare le occorrenze. Definisci il fuso orario e se recuperare le date aziendali saltate durante un'interruzione.

## 3. Proteggi la fattura, non soltanto il job

Supponiamo che un worker crei una fattura e si arresti prima di registrare il completamento del job. Il recupero può eseguire nuovamente il job anche se la fattura esiste già.

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

Usa una chiave aziendale stabile, come cliente e periodo di fatturazione. Per operazioni nel database locale, un vincolo di unicità e una transazione possono collegare la creazione della fattura alla registrazione dell'esecuzione completata. Un nuovo tentativo trova così il risultato esistente invece di creare un'altra fattura.

Per un fornitore esterno, usa la sua chiave di idempotenza quando disponibile e riconcilia gli esiti incerti. Un ID del job o un record del job conservato, da soli, non garantiscono permanentemente che un'azione aziendale non si ripeta. [Job idempotenti](https://docs.bullmq.io/patterns/idempotent-jobs).

## 4. Conosci garanzie e limiti di un lock

Un lock condiviso deve essere acquisito atomicamente. Usa un token di proprietà, una scadenza e il rinnovo; rilascialo soltanto quando il token corrisponde ancora. Altrimenti, un vecchio worker potrebbe rilasciare il lock di uno nuovo.

La scadenza introduce un altro caso: un worker sospeso riparte dopo la scadenza del proprio lease mentre un nuovo worker è già attivo. Le scritture critiche possono richiedere fencing token, numeri di proprietà crescenti che la destinazione controlla per rifiutare worker obsoleti. Impostare un timeout lungo non elimina questo rischio.

Se il coordinamento non è disponibile, decidi se il task debba attendere anziché procedere senza proprietà. Per operazioni importanti, attendere è spesso più sicuro.

## 5. Verifica i casi di errore

Prova più nodi, un arresto dopo la creazione della fattura, una pausa più lunga del lease, la perdita di connessione a Redis e un deployment progressivo. Registra data aziendale, worker, tentativo ed esito per distinguere tentativi ripetuti da effetti ripetuti.

**Da ricordare:** coordinare la pianificazione → limitare l'esecuzione condivisa → rendere sicuri i nuovi tentativi dell'azione aziendale → provare il recupero. “Un solo job attivo” non dimostra da solo un unico effetto aziendale.

Situazione	Opzione da valutare	Responsabilità che rimane
La piattaforma offre già job pianificati	Spostare la pianificazione fuori dalle istanze web	Configurare sovrapposizioni, recupero ed esecuzioni saltate.
Il team gestisce già BullMQ	Job Scheduler condiviso e coda dedicata	Configurare concorrenza condivisa e tentativi sicuri.
Il task deve restare sui nodi applicativi	Lock o lease condiviso	Gestire correttamente proprietà, scadenza e worker obsoleti.

1. Comprendi perché tutti i nodi avviano il task

2. Scegli il modello di coordinamento

3. Proteggi la fattura, non soltanto il job

4. Conosci garanzie e limiti di un lock

5. Verifica i casi di errore

Domande correlate