Hvordan koordinerer man et cronjob mellem flere NestJS-noder?

Question

IT Interview Practice · Accepted Answer

Definér først, hvad “kun én node kører cronjobbet” betyder. **At forhindre samtidig kørsel og at forhindre gentagen forretningseffekt er forskellige krav.** En fælles planlægger koordinerer kørsel; operationen skal selv være sikker efter nedbrud og gentagelse.

Overvej et dagligt fakturajob på tre NestJS-noder. Arbejdet skal køre uden at skabe en ekstra faktura, når en worker genstarter.

## 1. Forstå, hvorfor alle noder starter

Hver applikationsinstans registrerer sit eget cron-callback. På tidspunktet kan alle starte uafhængigt:

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

Et lokalt isRunning-flag findes kun i én proces. NestJS waitForCompletion kan forhindre overlappende callbacks dér, men koordinerer ikke andre noder. Samme flag på tre noder giver stadig tre beslutninger. [NestJS-planlægning](https://docs.nestjs.com/techniques/task-scheduling).

Derfor behøver vi et fælles sted, som afgør, hvilket arbejde der findes, og hvem der må behandle det.

## 2. Vælg koordinationsmodel

| Situation | Mulighed til vurdering | Resterende ansvar |
| --- | --- | --- |
| Platformen tilbyder allerede planlagte job | Placér planlægning uden for webinstanser | Konfigurér overlap, gendannelse og missede kørsler. |
| Teamet driver allerede BullMQ | Fælles Job Scheduler og dedikeret kø | Konfigurér fælles samtidighed og sikre gentagelser. |
| Opgaven skal blive på applikationsnoder | Delt lås eller lease | Håndtér ejerskab, udløb og gamle workers korrekt. |

Hvis Redis og BullMQ allerede findes til fakturaeksemplet, er en fælles planlægger med stabilt ID en praktisk kandidat. Adskil planen fra workers, så flere webnoder ikke opretter uafhængige planer.

På en understøttet BullMQ-version sættes køens globale samtidighed til én. Det begrænser aktive job på tværs af workers; lokal samtidighed én tillader stadig flere workers at køre forskellige job. [Global samtidighed](https://docs.bullmq.io/guide/queues/global-concurrency).

Beslut, hvad der sker, hvis gårsdagens arbejde stadig kører: vent, spring over eller kombinér forekomster. Definér tidszone og indhentning af missede forretningsdatoer efter nedetid.

## 3. Beskyt fakturaen, ikke kun jobbet

En worker kan oprette fakturaen og bryde ned, før jobbet markeres færdigt. Gendannelse kan gentage jobbet, selv om fakturaen allerede findes.

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

Brug en stabil forretningsnøgle som kunde og faktureringsperiode. Ved lokalt databasearbejde kan en unik constraint og en transaktion forbinde fakturaen med registreringen af gennemført kørsel. Gentagelsen finder så resultatet frem for at oprette en ny faktura.

Hos en ekstern udbyder bruges dennes idempotency key, hvis muligt, og usikre udfald afstemmes. Et køjob-ID eller en bevaret jobpost er ikke i sig selv en permanent garanti mod gentagen forretningshandling. [Idempotente job](https://docs.bullmq.io/patterns/idempotent-jobs).

## 4. Kend låsens garantier og begrænsninger

En delt lås skal erhverves atomisk. Brug ejerskabstoken, udløb og fornyelse; frigiv kun, når tokenet stadig matcher. Ellers kan en gammel worker frigive en nyere workers lås.

Udløb skaber endnu en situation: en pauset worker fortsætter efter sin lease, mens en ny allerede arbejder. Kritiske skrivninger kan kræve fencing tokens, stigende ejerskabsnumre, som destinationen kontrollerer for at afvise gamle workers. En lang timeout fjerner ikke risikoen.

Hvis koordinering er utilgængelig, så afgør, om opgaven skal vente frem for at køre uden ejerskab. Det er ofte sikrere ved betydningsfuldt arbejde.

## 5. Verificér fejltilfældene

Test flere noder, nedbrud efter fakturaoprettelse, pause længere end lease, tab af Redis-forbindelse og rullende udrulning. Registrér forretningsdato, worker, forsøg og resultat, så gentagne forsøg kan skelnes fra gentagne effekter.

**Husk:** koordinér planlægning → begræns fælles kørsel → gør handlingen sikker ved gentagelse → test gendannelse. “Ét aktivt job” beviser ikke præcis én forretningseffekt.

Situation	Mulighed til vurdering	Resterende ansvar
Platformen tilbyder allerede planlagte job	Placér planlægning uden for webinstanser	Konfigurér overlap, gendannelse og missede kørsler.
Teamet driver allerede BullMQ	Fælles Job Scheduler og dedikeret kø	Konfigurér fælles samtidighed og sikre gentagelser.
Opgaven skal blive på applikationsnoder	Delt lås eller lease	Håndtér ejerskab, udløb og gamle workers korrekt.

1. Forstå, hvorfor alle noder starter

2. Vælg koordinationsmodel

3. Beskyt fakturaen, ikke kun jobbet

4. Kend låsens garantier og begrænsninger

5. Verificér fejltilfældene

Relaterede spørgsmål