Unawezaje kuratibu cron job katika nodes nyingi za NestJS?

Question

IT Interview Practice · Accepted Answer

Kwanza fafanua maana ya “node moja tu inaendesha cronjob”. **Kuzuia utekelezaji wa wakati mmoja na kuzuia athari ya biashara kurudiwa ni mahitaji tofauti.** Scheduler ya pamoja huratibu utekelezaji; operation yenyewe lazima ibaki salama baada ya crash na retry.

Fikiria job ya kila siku ya ankara iliyowekwa kwenye nodes tatu za NestJS. Tunataka kazi iliyopangwa ifanyike bila kutoa ankara nyingine worker anapoanza upya.

## 1. Elewa kwa nini nodes zote zinaanza kazi

Kila instance ya programu husajili cron callback yake. Wakati uliopangwa, kila moja inaweza kuanza kivyake:

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

Flag ya ndani ya isRunning ipo katika process moja tu. NestJS waitForCompletion inaweza kuzuia callbacks kuingiliana kwenye instance hiyo, lakini hairatibu nodes nyingine. Kuongeza flag ileile kwenye nodes zote tatu bado huacha maamuzi matatu tofauti. [Scheduling ya NestJS](https://docs.nestjs.com/techniques/task-scheduling).

Kwa hiyo tunahitaji sehemu ya pamoja ya kuamua kazi iliyopo na anayekubaliwa kuichakata.

## 2. Chagua modeli ya uratibu

| Hali | Chaguo la kutathmini | Jukumu linalobaki |
| --- | --- | --- |
| Platform tayari ina scheduled jobs | Endesha scheduling nje ya web instances | Sanidi kuingiliana, urejeshaji na tabia ya runs zilizokosekana. |
| Timu tayari inaendesha BullMQ | Job Scheduler ya pamoja na queue maalumu | Sanidi concurrency ya pamoja na retries salama. |
| Kazi lazima ibaki kwenye application nodes | Lock au lease ya pamoja | Shughulikia ownership, expiry na workers waliopitwa na wakati kwa usahihi. |

Kwa mfano wa ankara, ikiwa Redis na BullMQ tayari zipo, scheduler ya pamoja yenye scheduler ID thabiti ni chaguo la vitendo. Tenganisha ratiba na workers ili kuongeza web nodes kusitengeneze ratiba zinazojitegemea.

Katika toleo la BullMQ linalounga mkono, weka global concurrency ya queue maalumu kuwa moja. Hii hupunguza active jobs kwa workers wote; local concurrency moja kwa kila worker bado huruhusu workers kadhaa kuendesha jobs tofauti. [Global concurrency](https://docs.bullmq.io/guide/queues/global-concurrency).

Amua cha kufanya ikiwa kazi ya jana bado inaendelea: kusubiri, kuruka au kuunganisha matukio. Fafanua eneo la saa na ikiwa siku za biashara zilizokosekana zitafidiwa baada ya downtime.

## 3. Linda ankara, si job pekee

Tuseme worker anatengeneza ankara na anacrash kabla ya kurekodi job imekamilika. Urejeshaji unaweza kuiendesha tena ingawa ankara tayari ipo.

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

Tumia business key thabiti, kama mteja pamoja na kipindi cha bili. Kwa kazi ya database ya ndani, unique constraint na transaction vinaweza kuunganisha kutengeneza ankara na rekodi ya run iliyokamilika. Retry basi hupata matokeo yaliyopo badala ya kutengeneza ankara nyingine.

Kwa provider wa nje, tumia idempotency key yake inapoungwa mkono na linganisha matokeo yasiyo na uhakika. Queue job ID au rekodi ya job iliyohifadhiwa peke yake si dhamana ya kudumu kwamba kitendo cha biashara hakiwezi kurudiwa. [Idempotent jobs](https://docs.bullmq.io/patterns/idempotent-jobs).

## 4. Jua lock inaweza na haiwezi kudhamini nini

Lock ya pamoja lazima ipatikane atomiki. Tumia ownership token, expiry na renewal; iachilie tu token ikiwa bado inalingana. Vinginevyo worker wa zamani anaweza kuachilia lock ya worker mpya.

Expiry huleta hali nyingine: worker aliyepumzishwa anarudi baada ya lease kuisha huku mpya tayari akiendesha. Uandishi muhimu unaweza kuhitaji fencing tokens, namba zinazoongezeka za ownership ambazo destination hukagua kukataa workers wa zamani. Kuweka timeout ndefu pekee hakuondoi hatari hii.

Ikiwa uratibu haupatikani, amua ikiwa kazi isubiri badala ya kuendesha bila ownership. Mara nyingi hili ni salama zaidi kwa kazi yenye athari muhimu.

## 5. Hakiki hali za kushindwa

Jaribu nodes nyingi, crash baada ya kutengeneza ankara, pause ndefu kuliko lease, kupotea kwa muunganisho wa Redis na rolling deployment. Rekodi tarehe ya biashara, worker, attempt na matokeo ili majaribio yanayorudiwa yatofautishwe na athari zinazojirudia.

**Kumbuka:** ratibu scheduling → punguza utekelezaji wa pamoja → fanya kitendo cha biashara kiwe salama kurudiwa → jaribu urejeshaji. “Job moja active” pekee si uthibitisho wa athari moja tu ya biashara.

Hali	Chaguo la kutathmini	Jukumu linalobaki
Platform tayari ina scheduled jobs	Endesha scheduling nje ya web instances	Sanidi kuingiliana, urejeshaji na tabia ya runs zilizokosekana.
Timu tayari inaendesha BullMQ	Job Scheduler ya pamoja na queue maalumu	Sanidi concurrency ya pamoja na retries salama.
Kazi lazima ibaki kwenye application nodes	Lock au lease ya pamoja	Shughulikia ownership, expiry na workers waliopitwa na wakati kwa usahihi.

1. Elewa kwa nini nodes zote zinaanza kazi

2. Chagua modeli ya uratibu

3. Linda ankara, si job pekee

4. Jua lock inaweza na haiwezi kudhamini nini

5. Hakiki hali za kushindwa

Maswali yanayohusiana