Hur samordnar du ett cron-jobb mellan flera NestJS-noder?

Question

IT Interview Practice · Accepted Answer

Definiera först vad ”bara en nod kör cronjobbet” betyder. **Att förhindra samtidig körning och att förhindra en upprepad verksamhetseffekt är olika krav.** En gemensam schemaläggare samordnar körningen; själva operationen måste förbli säker efter krasch och återförsök.

Tänk på ett dagligt faktureringsjobb på tre NestJS-noder. Vi vill köra det schemalagda arbetet utan att skapa en ny faktura när en worker startar om.

## 1. Förstå varför alla noder startar uppgiften

Varje applikationsinstans registrerar sin egen cron-callback. Vid den schemalagda tiden kan alla starta oberoende:

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

En lokal isRunning-flagga finns bara i en process. NestJS waitForCompletion kan hindra överlappande callbacks på den instansen, men samordnar inte andra noder. Samma flagga på tre noder ger fortfarande tre separata beslut. [Schemaläggning i NestJS](https://docs.nestjs.com/techniques/task-scheduling).

Vi behöver därför en gemensam plats som avgör vilket arbete som finns och vem som får bearbeta det.

## 2. Välj samordningsmodell

| Situation | Alternativ att utvärdera | Kvarvarande ansvar |
| --- | --- | --- |
| Plattformen har redan schemalagda jobb | Schemalägg utanför webbinstanserna | Konfigurera överlappning, återställning och missade körningar. |
| Teamet driver redan BullMQ | Gemensam Job Scheduler och dedikerad kö | Konfigurera gemensam samtidighet och säkra återförsök. |
| Uppgiften måste vara kvar på applikationsnoderna | Gemensamt lås eller tidsbegränsad lease | Hantera ägarskap, utgångstid och gamla workers korrekt. |

Om Redis och BullMQ redan finns är en gemensam schemaläggare med ett stabilt scheduler-ID ett praktiskt alternativ för faktureringen. Separera schemat från workers så att fler webbnoder inte skapar oberoende scheman.

I en BullMQ-version som stöder det, sätt den dedikerade köns globala samtidighet till ett. Det begränsar aktiva jobb över alla workers; lokal samtidighet ett per worker tillåter fortfarande flera workers att köra olika jobb. [Global samtidighet](https://docs.bullmq.io/guide/queues/global-concurrency).

Bestäm vad som händer om gårdagens arbete fortfarande körs: vänta, hoppa över eller slå samman tillfällen. Definiera tidszon och om missade verksamhetsdagar ska tas igen efter avbrott.

## 3. Skydda fakturan, inte bara jobbet

Anta att en worker skapar en faktura och kraschar innan jobbet markeras som klart. Återställningen kan köra jobbet igen trots att fakturan redan finns.

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

Använd en stabil verksamhetsnyckel, till exempel kund plus faktureringsperiod. För lokalt databasarbete kan en unikhetsbegränsning och en transaktion koppla fakturaskapandet till posten för den avslutade körningen. Ett återförsök hittar då det befintliga resultatet i stället för att skapa ännu en faktura.

För en extern leverantör, använd dess idempotensnyckel när den stöds och stäm av osäkra utfall. Ett köjobb-ID eller en sparad jobbpost är inte ensamt en permanent garanti mot upprepade verksamhetsåtgärder. [Idempotenta jobb](https://docs.bullmq.io/patterns/idempotent-jobs).

## 4. Förstå vad ett lås garanterar och inte garanterar

Ett gemensamt lås måste tas atomärt. Använd en ägartoken, utgångstid och förnyelse; släpp bara låset när token fortfarande stämmer. Annars kan en gammal worker släppa en nyare workers lås.

Utgångstiden skapar ett annat fall: en pausad worker återupptas efter att dess lease löpt ut medan en ny worker redan kör. Kritiska skrivningar kan behöva fencing tokens, stigande ägarnummer som målet kontrollerar för att avvisa gamla workers. En lång timeout tar inte bort risken.

Om samordningen är otillgänglig, avgör om uppgiften ska vänta i stället för att köra utan ägarskap. Det är ofta säkrare för arbete med viktiga konsekvenser.

## 5. Verifiera felsituationerna

Testa flera noder, en krasch efter fakturaskapandet, en paus längre än lease-tiden, förlorad Redis-anslutning och en rullande driftsättning. Logga verksamhetsdatum, worker, försök och utfall så att upprepade försök kan skiljas från upprepade effekter.

**Kom ihåg:** samordna schemaläggning → begränsa gemensam körning → gör verksamhetsåtgärden säker att försöka igen → testa återställning. ”Ett aktivt jobb” bevisar inte ensamt exakt en verksamhetseffekt.

Situation	Alternativ att utvärdera	Kvarvarande ansvar
Plattformen har redan schemalagda jobb	Schemalägg utanför webbinstanserna	Konfigurera överlappning, återställning och missade körningar.
Teamet driver redan BullMQ	Gemensam Job Scheduler och dedikerad kö	Konfigurera gemensam samtidighet och säkra återförsök.
Uppgiften måste vara kvar på applikationsnoderna	Gemensamt lås eller tidsbegränsad lease	Hantera ägarskap, utgångstid och gamla workers korrekt.

1. Förstå varför alla noder startar uppgiften

2. Välj samordningsmodell

3. Skydda fakturan, inte bara jobbet

4. Förstå vad ett lås garanterar och inte garanterar

5. Verifiera felsituationerna

Relaterade frågor