Kaip koordinuoti cron užduotį keliuose NestJS mazguose?

Question

IT Interview Practice · Accepted Answer

Pirmiausia apibrėžkite, ką reiškia „cron užduotį vykdo tik vienas mazgas“. **Vienalaikio vykdymo ir pasikartojančio verslo poveikio prevencija yra skirtingi reikalavimai.** Bendras planuoklis koordinuoja vykdymą, bet pati operacija turi būti saugi po gedimo ir pakartojimo.

Tarkime, kasdienis sąskaitų darbas įdiegtas trijuose NestJS mazguose. Norime jį atlikti, bet paleidus darbuotoją iš naujo nesukurti papildomos sąskaitos.

## 1. Supraskite, kodėl darbą pradeda visi mazgai

Kiekvienas programos egzempliorius registruoja savo cron funkciją. Nustatytu metu kiekvienas gali pradėti savarankiškai:

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

Vietinė isRunning žyma egzistuoja tik viename procese. NestJS waitForCompletion gali neleisti persidengti funkcijoms tame egzemplioriuje, bet nekoordinuoja kitų mazgų. Ta pati žyma visuose trijuose vis tiek palieka tris atskirus sprendimus. [NestJS planavimas](https://docs.nestjs.com/techniques/task-scheduling).

Todėl reikia bendros vietos nuspręsti, koks darbas egzistuoja ir kas gali jį atlikti.

## 2. Pasirinkite koordinavimo modelį

| Situacija | Vertinamas variantas | Likusi atsakomybė |
| --- | --- | --- |
| Platforma jau turi suplanuotas užduotis | Planuoti už žiniatinklio egzempliorių ribų | Persidengimas, atkūrimas ir praleisti vykdymai. |
| Komanda jau naudoja BullMQ | Bendras Job Scheduler ir atskira eilė | Bendra konkurencija ir saugūs kartojimai. |
| Darbas turi likti programos mazguose | Bendras užraktas arba nuoma | Nuosavybė, galiojimas ir pasenę darbuotojai. |

Sąskaitoms, jei Redis ir BullMQ jau veikia, bendras planuoklis su stabiliu ID yra praktiškas kandidatas. Atskirkite grafiką nuo darbuotojų, kad nauji žiniatinklio mazgai nekurtų nepriklausomų grafikų.

Palaikomoje BullMQ versijoje atskiros eilės globalų lygiagretumą nustatykite į vienetą. Tai riboja aktyvius darbus visuose darbuotojuose; vietinis vieneto limitas kiekviename vis dar leidžia keliems darbuotojams vykdyti skirtingus darbus. [Globalus lygiagretumas](https://docs.bullmq.io/guide/queues/global-concurrency).

Nuspręskite, ką daryti, jei vakar dienos darbas dar vyksta: laukti, praleisti ar sujungti pasikartojimus. Apibrėžkite laiko juostą ir praleistų verslo datų apdorojimą po prastovos.

## 3. Saugokite sąskaitą, ne tik užduotį

Darbuotojas gali sukurti sąskaitą ir sugesti prieš užrašydamas darbo pabaigą. Atkūrimas gali vykdyti darbą vėl, nors sąskaita jau yra.

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

Naudokite stabilų verslo raktą, pavyzdžiui, klientą ir atsiskaitymo laikotarpį. Vietinėje bazėje unikalumo apribojimas ir transakcija gali susieti sąskaitą su atlikto darbo įrašu. Pakartojimas randa esamą rezultatą, užuot sukūręs kitą sąskaitą.

Išoriniam tiekėjui naudokite jo idempotentiškumo raktą, jei palaikomas, ir sutikrinkite neaiškius rezultatus. Vien eilės darbo ID ar išsaugotas darbo įrašas nėra amžina garantija, kad verslo veiksmas nepasikartos. [Idempotentiški darbai](https://docs.bullmq.io/patterns/idempotent-jobs).

## 4. Žinokite užrakto garantijas ir ribas

Bendrą užraktą reikia įgyti atominiu būdu. Naudokite nuosavybės žymą, galiojimo laiką ir pratęsimą; atleiskite tik jei žyma dar sutampa. Kitaip senas darbuotojas gali atleisti naujojo užraktą.

Galiojimo pabaiga sukuria kitą atvejį: sustabdytas darbuotojas grįžta pasibaigus nuomai, kai naujas jau dirba. Kritiniams įrašymams gali reikėti fencing token — didėjančių nuosavybės numerių, kuriuos gavėjas tikrina ir atmeta pasenusius darbuotojus. Vien ilgas laukimo laikas šios rizikos nepašalina.

Jei koordinavimas nepasiekiamas, nuspręskite, ar darbas turėtų laukti, o ne veikti be nuosavybės. Svarbiems veiksmams laukimas dažnai saugesnis.

## 5. Patikrinkite gedimų scenarijus

Bandykite kelis mazgus, gedimą po sąskaitos sukūrimo, už nuomą ilgesnę pauzę, Redis ryšio praradimą ir laipsnišką diegimą. Registruokite verslo datą, darbuotoją, bandymą ir rezultatą, kad atskirtumėte kartotinius bandymus nuo kartotinių poveikių.

**Prisiminkite:** grafiko koordinavimas → bendro vykdymo ribojimas → saugus verslo veiksmo kartojimas → atkūrimo bandymas. „Vienas aktyvus darbas“ pats neįrodo vienintelio verslo poveikio.

Situacija	Vertinamas variantas	Likusi atsakomybė
Platforma jau turi suplanuotas užduotis	Planuoti už žiniatinklio egzempliorių ribų	Persidengimas, atkūrimas ir praleisti vykdymai.
Komanda jau naudoja BullMQ	Bendras Job Scheduler ir atskira eilė	Bendra konkurencija ir saugūs kartojimai.
Darbas turi likti programos mazguose	Bendras užraktas arba nuoma	Nuosavybė, galiojimas ir pasenę darbuotojai.

1. Supraskite, kodėl darbą pradeda visi mazgai

2. Pasirinkite koordinavimo modelį

3. Saugokite sąskaitą, ne tik užduotį

4. Žinokite užrakto garantijas ir ribas

5. Patikrinkite gedimų scenarijus

Susiję klausimai