Hvordan koordinerer du en cron-jobb på tvers av flere NestJS-noder?

Question

IT Interview Practice · Accepted Answer

Definer først hva «bare én node kjører cronjobben» betyr. **Å hindre samtidig kjøring og å hindre en gjentatt forretningseffekt er ulike krav.** En felles planlegger koordinerer kjøringen; selve operasjonen må tåle krasj og nye forsøk.

Tenk på en daglig fakturajobb på tre NestJS-noder. Arbeidet skal utføres uten å lage en ekstra faktura når en worker starter på nytt.

## 1. Forstå hvorfor alle nodene starter

Hver applikasjonsinstans registrerer sin egen cron-callback. På det planlagte tidspunktet kan alle starte uavhengig:

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

Et lokalt isRunning-flagg finnes bare i én prosess. NestJS waitForCompletion kan hindre overlappende callbacks på den instansen, men koordinerer ikke andre noder. Samme flagg på tre noder gir fortsatt tre separate beslutninger. [NestJS-planlegging](https://docs.nestjs.com/techniques/task-scheduling).

Vi trenger derfor et felles sted som avgjør hvilket arbeid som finnes, og hvem som kan behandle det.

## 2. Velg koordineringsmodell

| Situasjon | Alternativ å vurdere | Gjenstående ansvar |
| --- | --- | --- |
| Plattformen tilbyr allerede planlagte jobber | Legg planlegging utenfor webinstansene | Konfigurer overlapp, gjenoppretting og tapte kjøringer. |
| Teamet drifter allerede BullMQ | Felles Job Scheduler og egen kø | Konfigurer felles samtidighet og trygge nye forsøk. |
| Oppgaven må bli på applikasjonsnodene | Felles lås eller lease | Håndter eierskap, utløp og utdaterte workers riktig. |

Hvis Redis og BullMQ allerede finnes, er en felles planlegger med stabil scheduler-ID et praktisk alternativ for faktureringen. Skill tidsplanen fra workers slik at flere webnoder ikke oppretter uavhengige planer.

I en støttet BullMQ-versjon settes den dedikerte køens globale samtidighet til én. Dette begrenser aktive jobber på tvers av workers; lokal samtidighet på én per worker lar fortsatt flere workers kjøre ulike jobber. [Global samtidighet](https://docs.bullmq.io/guide/queues/global-concurrency).

Bestem hva som skjer hvis gårsdagens arbeid fortsatt kjører: vente, hoppe over eller kombinere forekomster. Definer tidssone og om tapte forretningsdatoer skal tas igjen etter nedetid.

## 3. Beskytt fakturaen, ikke bare jobben

Anta at en worker lager fakturaen og krasjer før jobben registreres som ferdig. Gjenoppretting kan kjøre jobben igjen selv om fakturaen finnes.

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

Bruk en stabil forretningsnøkkel, som kunde og fakturaperiode. For lokalt databasearbeid kan en unikhetsbegrensning og en transaksjon knytte fakturaen til registreringen av fullført kjøring. Et nytt forsøk finner da det eksisterende resultatet fremfor å lage en ekstra faktura.

For en ekstern leverandør brukes idempotensnøkkel når den støttes, og usikre utfall avstemmes. En køjobb-ID eller en beholdt jobbpost alene garanterer ikke permanent at en forretningshandling aldri gjentas. [Idempotente jobber](https://docs.bullmq.io/patterns/idempotent-jobs).

## 4. Vit hva en lås kan og ikke kan garantere

En felles lås må tas atomisk. Bruk eierskapstoken, utløp og fornyelse; frigjør bare når tokenet fortsatt stemmer. Ellers kan en gammel worker frigjøre en nyere workers lås.

Utløp gir et annet tilfelle: en pauset worker fortsetter etter at leasen utløper, mens en ny worker allerede kjører. Kritiske skrivinger kan trenge fencing tokens, stigende eierskapsnumre som mottakeren kontrollerer for å avvise utdaterte workers. En lang timeout alene fjerner ikke risikoen.

Hvis koordinering er utilgjengelig, avgjør om jobben skal vente i stedet for å kjøre uten eierskap. Dette er ofte tryggest for arbeid med viktige konsekvenser.

## 5. Kontroller feiltilfellene

Test flere noder, krasj etter fakturaoppretting, pause lengre enn leasen, bortfall av Redis-forbindelsen og rullerende utrulling. Registrer forretningsdato, worker, forsøk og utfall, slik at gjentatte forsøk kan skilles fra gjentatte effekter.

**Husk:** koordiner planlegging → begrens felles kjøring → gjør handlingen trygg å gjenta → test gjenoppretting. «Én aktiv jobb» beviser ikke alene nøyaktig én forretningseffekt.

Situasjon	Alternativ å vurdere	Gjenstående ansvar
Plattformen tilbyr allerede planlagte jobber	Legg planlegging utenfor webinstansene	Konfigurer overlapp, gjenoppretting og tapte kjøringer.
Teamet drifter allerede BullMQ	Felles Job Scheduler og egen kø	Konfigurer felles samtidighet og trygge nye forsøk.
Oppgaven må bli på applikasjonsnodene	Felles lås eller lease	Håndter eierskap, utløp og utdaterte workers riktig.

1. Forstå hvorfor alle nodene starter

2. Velg koordineringsmodell

3. Beskytt fakturaen, ikke bare jobben

4. Vit hva en lås kan og ikke kan garantere

5. Kontroller feiltilfellene

Relaterte spørsmål