Bagaimanakah cron diselaraskan merentas beberapa nod NestJS?

Question

IT Interview Practice · Accepted Answer

Tentukan dahulu maksud “hanya satu nod menjalankan cronjob”. **Mencegah pelaksanaan serentak dan mencegah kesan perniagaan berulang ialah keperluan berbeza.** Penjadual bersama menyelaraskan pelaksanaan; operasi itu sendiri mesti selamat selepas kerosakan dan percubaan semula.

Bayangkan tugas invois harian pada tiga nod NestJS. Kerja berjadual mesti berjalan tanpa mencipta invois tambahan apabila pekerja dimulakan semula.

## 1. Fahami mengapa semua nod memulakan tugas

Setiap tika aplikasi mendaftarkan panggilan balik cron sendiri. Pada masa dijadualkan, setiap satu boleh bermula secara bebas:

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

Bendera isRunning setempat hanya wujud dalam satu proses. waitForCompletion NestJS boleh mencegah pertindihan pada tika itu, tetapi tidak menyelaraskan nod lain. Bendera sama pada ketiga-tiganya masih menghasilkan tiga keputusan berasingan. [Penjadualan NestJS](https://docs.nestjs.com/techniques/task-scheduling).

Oleh itu, perlukan tempat bersama untuk menentukan kerja yang wujud dan pihak yang boleh memprosesnya.

## 2. Pilih model penyelarasan

| Keadaan | Pilihan untuk dinilai | Tanggungjawab yang kekal |
| --- | --- | --- |
| Platform sudah menyediakan tugas berjadual | Jadualkan di luar tika web | Tetapkan pertindihan, pemulihan dan jadual terlepas. |
| Pasukan sudah mengendalikan BullMQ | Job Scheduler bersama dan baris gilir khusus | Tetapkan keserentakan bersama dan percubaan selamat. |
| Tugas mesti kekal pada nod aplikasi | Kunci atau pajakan bersama | Urus pemilikan, luput dan pekerja lapuk dengan betul. |

Jika Redis dan BullMQ tersedia, penjadual bersama dengan ID stabil ialah calon praktikal untuk invois. Pisahkan jadual daripada pekerja agar penambahan nod web tidak mencipta jadual bebas.

Dalam versi BullMQ yang menyokongnya, tetapkan keserentakan global baris gilir khusus kepada satu. Ini mengehadkan tugas aktif merentas pekerja; had setempat satu pada setiap pekerja masih membolehkan beberapa pekerja menjalankan tugas berlainan. [Keserentakan global](https://docs.bullmq.io/guide/queues/global-concurrency).

Putuskan tindakan jika kerja semalam masih berjalan: tunggu, langkau atau gabungkan kejadian. Tentukan zon waktu dan sama ada tarikh perniagaan yang terlepas perlu diproses selepas gangguan.

## 3. Lindungi invois, bukan tugas sahaja

Andaikan pekerja mencipta invois lalu rosak sebelum mencatat tugas selesai. Pemulihan mungkin menjalankan tugas lagi walaupun invois sudah wujud.

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

Gunakan kunci perniagaan stabil, seperti pelanggan bersama tempoh bil. Dalam pangkalan data setempat, kekangan unik dan transaksi boleh menghubungkan invois dengan rekod pelaksanaan selesai. Percubaan semula menemui hasil sedia ada, bukan mencipta invois lain.

Untuk penyedia luar, gunakan kunci idempotensi jika disokong dan selaraskan hasil yang tidak pasti. ID tugas atau rekod tugas tersimpan sahaja bukan jaminan kekal bahawa tindakan perniagaan tidak boleh berulang. [Tugas idempoten](https://docs.bullmq.io/patterns/idempotent-jobs).

## 4. Ketahui jaminan dan batas kunci

Kunci bersama mesti diperoleh secara atomik. Gunakan token pemilikan, tempoh luput dan pembaharuan; lepaskan hanya jika token masih sepadan. Jika tidak, pekerja lama boleh melepaskan kunci pekerja baharu.

Luput mewujudkan kes lain: pekerja terhenti menyambung selepas pajakannya tamat sementara pekerja baharu sudah berjalan. Penulisan kritikal mungkin memerlukan fencing token, nombor pemilikan meningkat yang disemak destinasi untuk menolak pekerja lama. Timeout panjang sahaja tidak menghapuskan risiko ini.

Jika penyelarasan tidak tersedia, putuskan sama ada tugas perlu menunggu daripada berjalan tanpa pemilikan. Bagi kerja berakibat penting, menunggu sering lebih selamat.

## 5. Sahkan kes kegagalan

Uji berbilang nod, kerosakan selepas invois dicipta, jeda melebihi pajakan, kehilangan sambungan Redis dan pelaksanaan bergilir. Catat tarikh perniagaan, pekerja, percubaan dan hasil untuk membezakan cubaan berulang daripada kesan berulang.

**Ingat:** selaraskan jadual → hadkan pelaksanaan bersama → jadikan tindakan selamat dicuba semula → uji pemulihan. “Satu tugas aktif” sahaja tidak membuktikan tepat satu kesan perniagaan.

Keadaan	Pilihan untuk dinilai	Tanggungjawab yang kekal
Platform sudah menyediakan tugas berjadual	Jadualkan di luar tika web	Tetapkan pertindihan, pemulihan dan jadual terlepas.
Pasukan sudah mengendalikan BullMQ	Job Scheduler bersama dan baris gilir khusus	Tetapkan keserentakan bersama dan percubaan selamat.
Tugas mesti kekal pada nod aplikasi	Kunci atau pajakan bersama	Urus pemilikan, luput dan pekerja lapuk dengan betul.

1. Fahami mengapa semua nod memulakan tugas

2. Pilih model penyelarasan

3. Lindungi invois, bukan tugas sahaja

4. Ketahui jaminan dan batas kunci

5. Sahkan kes kegagalan

Soalan berkaitan