Si koordinohet një cron job në disa nyje NestJS?

Question

IT Interview Practice · Accepted Answer

Së pari përcaktoni çfarë do të thotë “vetëm një nyje ekzekuton cronjob-in”. **Parandalimi i ekzekutimit të njëkohshëm dhe parandalimi i përsëritjes së efektit të biznesit janë kërkesa të ndryshme.** Një planifikues i përbashkët koordinon ekzekutimin; vetë operacioni duhet të mbetet i sigurt pas ndërprerjes dhe riprovimit.

Merrni një punë ditore faturimi të vendosur në tri nyje NestJS. Duam që puna e planifikuar të kryhet, pa gjeneruar faturë tjetër kur një worker riniset.

## 1. Kuptoni pse të gjitha nyjet e nisin detyrën

Çdo instancë e aplikacionit regjistron callback-un e vet cron. Në kohën e caktuar, secila mund të nisë në mënyrë të pavarur:

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

Flamuri lokal isRunning ekziston vetëm në një proces. NestJS waitForCompletion mund të ndalojë mbivendosjen e callback-eve në atë instancë, por nuk koordinon nyjet e tjera. Vendosja e të njëjtit flamur në të tria nyjet përsëri lë tri vendime të ndara. [Planifikimi në NestJS](https://docs.nestjs.com/techniques/task-scheduling).

Prandaj na duhet një vend i përbashkët për të vendosur çfarë pune ekziston dhe kush mund ta përpunojë.

## 2. Zgjidhni modelin e koordinimit

| Situata | Mundësia për vlerësim | Përgjegjësia që mbetet |
| --- | --- | --- |
| Platforma tashmë ofron punë të planifikuara | Kryeni planifikimin jashtë instancave web | Konfiguroni mbivendosjen, rikuperimin dhe ekzekutimet e humbura. |
| Ekipi tashmë operon BullMQ | Job Scheduler i përbashkët dhe radhë e dedikuar | Konfiguroni konkurrencën e përbashkët dhe riprovimet e sigurta. |
| Detyra ekzistuese duhet të mbetet në nyjet e aplikacionit | Lock ose lease i përbashkët | Trajtoni saktë pronësinë, skadimin dhe worker-at e vjetruar. |

Për faturimin, nëse Redis dhe BullMQ ekzistojnë tashmë, një planifikues i përbashkët me scheduler ID të qëndrueshme është një kandidat praktik. Ndani orarin nga worker-at që shtimi i nyjeve web të mos krijojë orare të pavarura.

Në një version BullMQ që e mbështet, vendosni global concurrency të radhës së dedikuar në një. Kjo kufizon punët aktive ndërmjet worker-ave; concurrency lokale një në çdo worker ende lejon disa worker-a të kryejnë punë të ndryshme. [Global concurrency](https://docs.bullmq.io/guide/queues/global-concurrency).

Vendosni çfarë ndodh nëse puna e djeshme ende vazhdon: prisni, anashkaloni apo bashkoni ekzekutimet. Përcaktoni zonën kohore dhe nëse datat e humbura të biznesit duhen plotësuar pas ndërprerjes.

## 3. Mbroni faturën, jo vetëm punën

Supozoni se worker-i krijon një faturë dhe ndërpritet përpara se të regjistrojë përfundimin e punës. Rikuperimi mund ta kryejë sërish punën edhe pse fatura ekziston.

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

Përdorni çelës biznesi të qëndrueshëm, si klienti bashkë me periudhën e faturimit. Për punën në databazën lokale, një kufizim uniciteti dhe një transaksion mund ta lidhin krijimin e faturës me regjistrimin e ekzekutimit të përfunduar. Riprovimi gjen rezultatin ekzistues në vend që të krijojë faturë tjetër.

Për një ofrues të jashtëm, përdorni idempotency key kur mbështetet dhe rakordoni rezultatet e pasigurta. Vetëm ID-ja e punës në radhë ose regjistrimi i ruajtur i saj nuk është garanci e përhershme se veprimi i biznesit nuk mund të përsëritet. [Punë idempotente](https://docs.bullmq.io/patterns/idempotent-jobs).

## 4. Kuptoni çfarë garanton dhe çfarë nuk garanton lock-u

Një lock i përbashkët duhet marrë në mënyrë atomike. Përdorni token pronësie, skadim dhe rinovim; lirojeni vetëm kur token-i ende përputhet. Përndryshe një worker i vjetër mund të lirojë lock-un e një worker-i të ri.

Skadimi krijon një rast tjetër: worker-i i pezulluar rifillon pasi lease-i i tij skadon, ndërkohë që worker-i i ri po punon. Shkrimet kritike mund të kërkojnë fencing tokens, numra pronësie në rritje që destinacioni i kontrollon për të refuzuar worker-at e vjetruar. Vetëm një timeout i gjatë nuk e eliminon këtë rrezik.

Nëse koordinimi nuk është i disponueshëm, vendosni nëse detyra duhet të presë në vend që të ekzekutohet pa pronësi. Kjo shpesh është zgjedhja më e sigurt për punë me pasoja të rëndësishme.

## 5. Verifikoni rastet e dështimit

Testoni shumë nyje, ndërprerjen pas krijimit të faturës, një pauzë më të gjatë se lease-i, humbjen e lidhjes me Redis dhe një vendosje graduale. Regjistroni datën e biznesit, worker-in, përpjekjen dhe rezultatin që përpjekjet e përsëritura të dallohen nga efektet e përsëritura.

**Mbani mend:** koordinoni planifikimin → kufizoni ekzekutimin e përbashkët → bëjeni veprimin e biznesit të sigurt për riprovim → testoni rikuperimin. “Një punë aktive” nuk provon vetvetiu saktësisht një efekt biznesi.

Situata	Mundësia për vlerësim	Përgjegjësia që mbetet
Platforma tashmë ofron punë të planifikuara	Kryeni planifikimin jashtë instancave web	Konfiguroni mbivendosjen, rikuperimin dhe ekzekutimet e humbura.
Ekipi tashmë operon BullMQ	Job Scheduler i përbashkët dhe radhë e dedikuar	Konfiguroni konkurrencën e përbashkët dhe riprovimet e sigurta.
Detyra ekzistuese duhet të mbetet në nyjet e aplikacionit	Lock ose lease i përbashkët	Trajtoni saktë pronësinë, skadimin dhe worker-at e vjetruar.

1. Kuptoni pse të gjitha nyjet e nisin detyrën

2. Zgjidhni modelin e koordinimit

3. Mbroni faturën, jo vetëm punën

4. Kuptoni çfarë garanton dhe çfarë nuk garanton lock-u

5. Verifikoni rastet e dështimit

Pyetje të ngjashme