Ta yaya za ka daidaita cron job tsakanin nodes na NestJS da yawa?

Question

IT Interview Practice · Accepted Answer

Da farko bayyana ma’anar “node ɗaya kawai yana gudanar da cronjob”. **Hana execution na lokaci guda da hana maimaita sakamakon kasuwanci buƙatu ne daban.** Shared scheduler yana daidaita execution; aikin kansa dole ya kasance amintacce bayan crash da retry.

Ka ɗauki aikin invoice na kullum da aka saka a nodes uku na NestJS. Muna son aikin ya gudana, amma kada sake farawar worker ya ƙirƙiri wani invoice.

## 1. Fahimci dalilin da duk nodes suke fara aikin

Kowane application instance yana rajistar cron callback nasa. A lokacin da aka tsara, kowanne zai iya farawa da kansa:

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

Local isRunning flag yana cikin process ɗaya kawai. waitForCompletion na NestJS zai iya hana callbacks su rufe juna a instance ɗin, amma ba ya daidaita sauran nodes. Saka flag ɗaya a nodes uku har yanzu yana barin shawara uku daban. [NestJS scheduling](https://docs.nestjs.com/techniques/task-scheduling).

Saboda haka muna buƙatar wurin da kowa yake rabawa don tantance aikin da yake akwai da wanda zai iya sarrafa shi.

## 2. Zaɓi tsarin daidaitawa

| Yanayi | Zaɓin da za a tantance | Nauyin da ya rage |
| --- | --- | --- |
| Platform yana da scheduled jobs tuni | Gudanar da scheduling a wajen web instances | Tsara overlap, recovery da missed runs. |
| Ƙungiya tana amfani da BullMQ tuni | Shared Job Scheduler da queue na musamman | Tsara shared concurrency da safe retries. |
| Aikin dole ya zauna a application nodes | Shared lock ko lease | Kula da ownership, expiry da stale workers yadda ya kamata. |

Ga invoice, idan Redis da BullMQ suna nan, shared scheduler mai stable scheduler ID zaɓi ne mai amfani. Ware schedule daga workers don ƙara web nodes kada ya ƙirƙiri schedules daban.

A sigar BullMQ da ke goyon baya, sa global concurrency na queue na musamman zuwa ɗaya. Wannan yana takaita active jobs a duk workers; local concurrency ɗaya a kowane worker har yanzu yana barin workers da yawa su gudanar da jobs daban. [Global concurrency](https://docs.bullmq.io/guide/queues/global-concurrency).

Yanke abin da za a yi idan aikin jiya yana gudana har yanzu: jira, tsallake ko haɗa occurrences. Bayyana time zone da ko za a cike kwanakin kasuwanci da aka rasa bayan downtime.

## 3. Kare invoice, ba job kawai ba

A ce worker ya ƙirƙiri invoice kuma ya crash kafin rubuta completion. Recovery na iya sake gudanar da job duk da invoice yana nan.

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

Yi amfani da stable business key, kamar customer da billing period. Ga aiki a local database, unique constraint da transaction za su iya haɗa ƙirƙirar invoice da rikodin completed run. Retry ya samo sakamakon da yake akwai maimakon ƙirƙirar wani.

Ga external provider, amfani da idempotency key nasa idan akwai, kuma reconcile sakamakon da ba a tabbatar ba. Queue job ID ko ajiyayyen job record shi kaɗai ba tabbacin dindindin ba ne cewa business action ba zai maimaitu ba. [Idempotent jobs](https://docs.bullmq.io/patterns/idempotent-jobs).

## 4. San abin da lock zai iya da wanda ba zai iya tabbatarwa ba

Dole a samu shared lock atomically. Yi amfani da ownership token, expiry da renewal; a sake shi ne kawai idan token har yanzu ya dace. In ba haka ba, tsohon worker zai iya sake lock na sabon worker.

Expiry yana kawo wani hali: worker da aka dakata ya dawo bayan lease ya ƙare, yayin da sabon worker yana aiki. Critical writes na iya buƙatar fencing tokens, lambobin ownership masu ƙaruwa da destination yake dubawa don ƙin stale workers. Dogon timeout kawai ba ya cire wannan haɗari.

Idan coordination ba ya samuwa, yanke ko aikin ya jira maimakon ya gudana ba tare da ownership ba. Wannan yawanci ya fi aminci ga ayyuka masu muhimmiyar tasiri.

## 5. Tabbatar da yanayin gazawa

Gwada nodes da yawa, crash bayan invoice, pause mafi tsawo da lease, rasa haɗin Redis da rolling deployment. Rubuta business date, worker, attempt da outcome don bambanta maimaita ƙoƙari daga maimaita tasiri.

**Ka tuna:** daidaita scheduling → takaita shared execution → sa business action ya zama retry-safe → gwada recovery. “Active job ɗaya” shi kaɗai ba hujjar business effect ɗaya tak ba ne.

Yanayi	Zaɓin da za a tantance	Nauyin da ya rage
Platform yana da scheduled jobs tuni	Gudanar da scheduling a wajen web instances	Tsara overlap, recovery da missed runs.
Ƙungiya tana amfani da BullMQ tuni	Shared Job Scheduler da queue na musamman	Tsara shared concurrency da safe retries.
Aikin dole ya zauna a application nodes	Shared lock ko lease	Kula da ownership, expiry da stale workers yadda ya kamata.

1. Fahimci dalilin da duk nodes suke fara aikin

2. Zaɓi tsarin daidaitawa

3. Kare invoice, ba job kawai ba

4. San abin da lock zai iya da wanda ba zai iya tabbatarwa ba

5. Tabbatar da yanayin gazawa

Tambayoyi masu alaƙa