Wie koordiniert man einen Cronjob über mehrere NestJS-Knoten?

Question

IT Interview Practice · Accepted Answer

Klären Sie zuerst, was „nur ein Knoten führt den Cronjob aus“ bedeutet. **Gleichzeitige Ausführung und wiederholte fachliche Wirkung zu verhindern sind unterschiedliche Anforderungen.** Ein gemeinsamer Scheduler koordiniert die Ausführung; die Operation muss auch nach Absturz und Wiederholung sicher bleiben.

Betrachten wir einen täglichen Rechnungsjob auf drei NestJS-Knoten. Er soll laufen, ohne nach einem Worker-Neustart eine zusätzliche Rechnung zu erzeugen.

## 1. Verstehen Sie den Start auf allen Knoten

Jede Anwendungsinstanz registriert ihren eigenen Cron-Callback. Zum Termin kann jede unabhängig starten:

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

Ein lokales isRunning-Flag existiert nur in einem Prozess. NestJS waitForCompletion verhindert überlappende Callbacks auf dieser Instanz, koordiniert aber keine anderen Knoten. Drei gleiche Flags bleiben drei Entscheidungen. [NestJS-Scheduling](https://docs.nestjs.com/techniques/task-scheduling).

Deshalb brauchen wir eine gemeinsame Stelle, die vorhandene Arbeit und deren Bearbeiter bestimmt.

## 2. Wählen Sie das Koordinationsmodell

| Situation | Zu prüfende Option | Verbleibende Verantwortung |
| --- | --- | --- |
| Plattform bietet geplante Jobs | Scheduling außerhalb der Webinstanzen | Überlappung, Wiederherstellung und verpasste Termine regeln. |
| Team betreibt bereits BullMQ | Gemeinsamer Job Scheduler und eigene Queue | Gemeinsame Parallelität und sichere Wiederholungen konfigurieren. |
| Aufgabe muss auf Anwendungsknoten bleiben | Gemeinsame Sperre oder Lease | Besitz, Ablauf und veraltete Worker korrekt behandeln. |

Sind Redis und BullMQ bereits vorhanden, ist ein gemeinsamer Scheduler mit stabiler ID für die Rechnung ein praktischer Kandidat. Trennen Sie Zeitplan und Worker, damit zusätzliche Webknoten keine unabhängigen Zeitpläne schaffen.

In einer unterstützten BullMQ-Version begrenzen Sie die globale Parallelität der eigenen Queue auf eins. Das begrenzt aktive Jobs über Worker hinweg; lokale Parallelität eins lässt weiterhin mehrere Worker unterschiedliche Jobs ausführen. [Globale Parallelität](https://docs.bullmq.io/guide/queues/global-concurrency).

Legen Sie fest, was bei noch laufender Vortagsarbeit geschieht: warten, überspringen oder Termine zusammenführen. Definieren Sie Zeitzone und Nachholen verpasster Geschäftstage nach Ausfällen.

## 3. Schützen Sie die Rechnung, nicht nur den Job

Ein Worker erzeugt möglicherweise eine Rechnung und stürzt vor der Fertigmeldung ab. Die Wiederherstellung kann den Job trotz bestehender Rechnung erneut ausführen.

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

Verwenden Sie einen stabilen fachlichen Schlüssel, etwa Kunde plus Abrechnungszeitraum. Bei lokaler Datenbankarbeit können Eindeutigkeitsbedingung und Transaktion Rechnung und Abschlussdatensatz verbinden. Die Wiederholung findet dann das Ergebnis statt einer weiteren Rechnung.

Bei externen Anbietern nutzen Sie unterstützte Idempotenzschlüssel und gleichen unklare Ergebnisse ab. Eine Queue-Job-ID oder aufbewahrte Jobzeile allein ist keine dauerhafte Garantie gegen wiederholte Geschäftsaktionen. [Idempotente Jobs](https://docs.bullmq.io/patterns/idempotent-jobs).

## 4. Kennen Sie Grenzen einer Sperre

Die gemeinsame Sperre muss atomar erworben werden. Verwenden Sie Besitz-Token, Ablauf und Erneuerung; freigeben dürfen Sie nur bei übereinstimmendem Token. Sonst löst ein alter Worker möglicherweise die Sperre eines neuen.

Ablauf schafft einen weiteren Fall: Ein pausierter Worker läuft nach seiner Lease weiter, während ein neuer bereits arbeitet. Kritische Schreibzugriffe können Fencing Tokens benötigen: steigende Besitznummern, mit denen das Ziel alte Worker ablehnt. Eine lange Zeitüberschreitung beseitigt das Risiko nicht.

Fällt Koordination aus, entscheiden Sie, ob der Job wartet statt ohne Besitz zu laufen. Bei folgenreicher Arbeit ist das häufig sicherer.

## 5. Prüfen Sie Fehlerfälle

Testen Sie mehrere Knoten, Absturz nach Rechnungserzeugung, Pause über die Lease hinaus, Redis-Verbindungsverlust und Rolling Deployment. Protokollieren Sie Geschäftstag, Worker, Versuch und Ergebnis, um Versuche von Wirkungen zu unterscheiden.

**Merksatz:** Zeitplanung koordinieren → gemeinsame Ausführung begrenzen → fachliche Aktion wiederholungssicher machen → Wiederherstellung testen. „Ein aktiver Job“ beweist noch nicht genau eine fachliche Wirkung.

Situation	Zu prüfende Option	Verbleibende Verantwortung
Plattform bietet geplante Jobs	Scheduling außerhalb der Webinstanzen	Überlappung, Wiederherstellung und verpasste Termine regeln.
Team betreibt bereits BullMQ	Gemeinsamer Job Scheduler und eigene Queue	Gemeinsame Parallelität und sichere Wiederholungen konfigurieren.
Aufgabe muss auf Anwendungsknoten bleiben	Gemeinsame Sperre oder Lease	Besitz, Ablauf und veraltete Worker korrekt behandeln.

1. Verstehen Sie den Start auf allen Knoten

2. Wählen Sie das Koordinationsmodell

3. Schützen Sie die Rechnung, nicht nur den Job

4. Kennen Sie Grenzen einer Sperre

5. Prüfen Sie Fehlerfälle

Ähnliche Fragen