Jak koordinovat cron úlohu mezi více uzly NestJS?

Question

IT Interview Practice · Accepted Answer

Nejprve určete, co znamená „cronjob spouští jen jeden uzel“. **Zabránit souběžnému spuštění a zabránit opakovanému obchodnímu účinku jsou jiné požadavky.** Sdílený plánovač koordinuje běh; samotná operace musí být bezpečná i po pádu a opakování.

Uvažujme denní fakturační úlohu nasazenou na třech uzlech NestJS. Chceme provést naplánovanou práci bez další faktury po restartu workeru.

## 1. Pochopte, proč úlohu spouštějí všechny uzly

Každá instance aplikace registruje vlastní cron callback. V určeném čase může každá začít nezávisle:

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

Lokální příznak isRunning existuje jen v jednom procesu. NestJS waitForCompletion zabrání překrývání callbacků na dané instanci, ale nekoordinuje ostatní uzly. Stejný příznak na třech uzlech pořád znamená tři oddělená rozhodnutí. [Plánování v NestJS](https://docs.nestjs.com/techniques/task-scheduling).

Potřebujeme tedy společné místo pro rozhodnutí, jaká práce existuje a kdo ji smí provést.

## 2. Vyberte model koordinace

| Situace | Možnost k posouzení | Zbývající odpovědnost |
| --- | --- | --- |
| Platforma už poskytuje plánované úlohy | Plánování mimo webové instance | Nastavit překryv, obnovu a zmeškaná spuštění. |
| Tým už provozuje BullMQ | Sdílený Job Scheduler a vyhrazená fronta | Nastavit společný souběh a bezpečné opakování. |
| Úloha musí zůstat na aplikačních uzlech | Sdílený zámek nebo lease | Správně řešit vlastníka, expiraci a staré workery. |

Pokud už pro fakturaci existují Redis a BullMQ, praktickou možností je sdílený plánovač se stabilním ID. Oddělte plán od workerů, aby přidání webových uzlů nevytvářelo nezávislé plány.

V podporované verzi BullMQ nastavte globální souběh vyhrazené fronty na jedna. Tím omezíte aktivní úlohy napříč workery; lokální souběh jedna na každém workeru stále umožní více workerům provádět různé úlohy. [Globální souběh](https://docs.bullmq.io/guide/queues/global-concurrency).

Určete, co dělat, když včerejší práce stále běží: čekat, přeskočit, nebo spojit výskyty. Stanovte časové pásmo a dohánění zmeškaných obchodních dnů po výpadku.

## 3. Chraňte fakturu, nejen úlohu

Worker může vytvořit fakturu a spadnout před zaznamenáním dokončení. Obnova může úlohu spustit znovu, přestože faktura existuje.

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

Použijte stabilní obchodní klíč, například zákazníka a fakturační období. U práce v jedné databázi může unikátní omezení a transakce spojit fakturu se záznamem dokončeného běhu. Opakování potom najde existující výsledek místo vytvoření další faktury.

U externího poskytovatele použijte podporovaný idempotency key a ověřujte nejasné výsledky. Samotné ID úlohy nebo uchovaný záznam fronty nezaručí navždy, že se obchodní akce nezopakuje. [Idempotentní úlohy](https://docs.bullmq.io/patterns/idempotent-jobs).

## 4. Znejte možnosti a hranice zámku

Sdílený zámek musíte získat atomicky. Použijte token vlastníka, expiraci a obnovování; uvolňujte pouze při shodě tokenu. Jinak starý worker může uvolnit zámek novějšího.

Expirace přidává případ, kdy pozastavený worker pokračuje po vypršení lease a nový worker už běží. Kritické zápisy mohou potřebovat fencing tokeny: rostoucí čísla vlastnictví, podle kterých cíl odmítne zastaralé workery. Dlouhý timeout toto riziko neodstraní.

Při nedostupné koordinaci určete, zda úloha raději počká, než aby běžela bez vlastnictví. U důsledkově významné práce to bývá bezpečnější.

## 5. Ověřte chybové situace

Testujte více uzlů, pád po vytvoření faktury, pauzu delší než lease, ztrátu spojení s Redis a postupné nasazování. Zaznamenávejte obchodní datum, worker, pokus a výsledek, abyste odlišili opakované pokusy od opakovaných účinků.

**Zapamatujte si:** koordinovat plán → omezit společný běh → zajistit bezpečné opakování obchodní akce → testovat obnovu. „Jedna aktivní úloha“ sama nedokazuje právě jeden obchodní účinek.

Situace	Možnost k posouzení	Zbývající odpovědnost
Platforma už poskytuje plánované úlohy	Plánování mimo webové instance	Nastavit překryv, obnovu a zmeškaná spuštění.
Tým už provozuje BullMQ	Sdílený Job Scheduler a vyhrazená fronta	Nastavit společný souběh a bezpečné opakování.
Úloha musí zůstat na aplikačních uzlech	Sdílený zámek nebo lease	Správně řešit vlastníka, expiraci a staré workery.

1. Pochopte, proč úlohu spouštějí všechny uzly

2. Vyberte model koordinace

3. Chraňte fakturu, nejen úlohu

4. Znejte možnosti a hranice zámku

5. Ověřte chybové situace

Související otázky