Πώς συντονίζετε ένα cron job σε πολλούς κόμβους NestJS;

Question

IT Interview Practice · Accepted Answer

Ορίστε πρώτα τι σημαίνει «μόνο ένας κόμβος εκτελεί το cronjob». **Η αποφυγή ταυτόχρονης εκτέλεσης και η αποφυγή διπλού επιχειρησιακού αποτελέσματος είναι διαφορετικές απαιτήσεις.** Ο κοινός scheduler συντονίζει την εκτέλεση· η λειτουργία πρέπει να είναι ασφαλής μετά από διακοπή και επανάληψη.

Σκεφτείτε καθημερινή τιμολόγηση σε τρεις κόμβους NestJS. Θέλουμε να εκτελείται χωρίς δεύτερο τιμολόγιο μετά από επανεκκίνηση worker.

## 1. Καταλάβετε γιατί ξεκινούν όλοι οι κόμβοι

Κάθε instance καταχωρίζει δικό του cron callback. Την προγραμματισμένη στιγμή όλοι μπορούν να ξεκινήσουν ανεξάρτητα:

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

Μια τοπική σημαία isRunning υπάρχει μόνο σε μία διεργασία. Το waitForCompletion του NestJS αποτρέπει επικάλυψη στο ίδιο instance, όχι σε άλλους κόμβους. Τρεις ίδιες σημαίες παραμένουν τρεις αποφάσεις. [Προγραμματισμός NestJS](https://docs.nestjs.com/techniques/task-scheduling).

Χρειαζόμαστε κοινό σημείο απόφασης για την εργασία και το δικαίωμα εκτέλεσής της.

## 2. Επιλέξτε μοντέλο συντονισμού

| Περίπτωση | Επιλογή αξιολόγησης | Ευθύνη που παραμένει |
| --- | --- | --- |
| Η πλατφόρμα παρέχει προγραμματισμένα jobs | Scheduling έξω από web instances | Ρύθμιση επικάλυψης, ανάκτησης και χαμένων εκτελέσεων. |
| Η ομάδα λειτουργεί ήδη BullMQ | Κοινός Job Scheduler και ειδική ουρά | Κοινός παραλληλισμός και ασφαλείς επαναλήψεις. |
| Η εργασία πρέπει να μείνει στους κόμβους | Κοινό lock ή lease | Σωστή κυριότητα, λήξη και παλιοί workers. |

Αν υπάρχουν Redis και BullMQ, κοινός scheduler με σταθερό ID είναι πρακτικός υποψήφιος. Χωρίστε πρόγραμμα και workers, ώστε νέοι web κόμβοι να μη δημιουργούν ανεξάρτητα προγράμματα.

Σε υποστηριζόμενη έκδοση BullMQ, θέστε global concurrency της ειδικής ουράς σε ένα. Περιορίζει ενεργά jobs σε όλους τους workers· local concurrency ένα επιτρέπει ακόμη πολλούς workers με διαφορετικά jobs. [Global concurrency](https://docs.bullmq.io/guide/queues/global-concurrency).

Αποφασίστε αν η χθεσινή εργασία συνεχίζεται: αναμονή, παράλειψη ή συνδυασμός εκτελέσεων. Ορίστε ζώνη ώρας και αναπλήρωση χαμένων επιχειρησιακών ημερών μετά από διακοπή.

## 3. Προστατεύστε το τιμολόγιο, όχι μόνο το job

Ένας worker δημιουργεί τιμολόγιο και καταρρέει πριν καταγράψει ολοκλήρωση. Η ανάκαμψη μπορεί να επαναλάβει το job παρότι το τιμολόγιο υπάρχει.

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

Χρησιμοποιήστε σταθερό επιχειρησιακό κλειδί, όπως πελάτη και περίοδο χρέωσης. Σε τοπική βάση, μοναδικός περιορισμός και συναλλαγή συνδέουν τιμολόγιο και καταγραφή ολοκλήρωσης. Η επανάληψη βρίσκει το αποτέλεσμα αντί να δημιουργεί άλλο.

Για εξωτερικό πάροχο χρησιμοποιήστε υποστηριζόμενο idempotency key και συμφωνήστε αβέβαια αποτελέσματα. Ένα job ID ή διατηρημένη εγγραφή ουράς δεν εγγυάται μόνιμα ότι η πράξη δεν επαναλαμβάνεται. [Idempotent jobs](https://docs.bullmq.io/patterns/idempotent-jobs).

## 4. Γνωρίστε τα όρια του lock

Το κοινό lock αποκτάται ατομικά. Χρησιμοποιήστε token κυριότητας, λήξη και ανανέωση· αποδεσμεύστε μόνο με ίδιο token. Διαφορετικά παλιός worker μπορεί να λύσει το lock νεότερου.

Με τη λήξη, ένας παγωμένος worker μπορεί να συνεχίσει ενώ νέος ήδη εργάζεται. Κρίσιμες εγγραφές ίσως χρειάζονται fencing tokens: αυξανόμενους αριθμούς κυριότητας που ο προορισμός ελέγχει για απόρριψη παλιών workers. Μεγάλο timeout δεν εξαφανίζει τον κίνδυνο.

Αν ο συντονισμός δεν είναι διαθέσιμος, αποφασίστε αν η εργασία περιμένει αντί να εκτελείται χωρίς κυριότητα. Για σημαντικές συνέπειες αυτό συχνά είναι ασφαλέστερο.

## 5. Ελέγξτε αποτυχίες

Δοκιμάστε πολλούς κόμβους, πτώση μετά τη δημιουργία τιμολογίου, παύση μεγαλύτερη από lease, απώλεια Redis και σταδιακό deployment. Καταγράψτε ημερομηνία, worker, προσπάθεια και αποτέλεσμα για διάκριση επαναλήψεων προσπάθειας και επίδρασης.

**Θυμηθείτε:** κοινό scheduling → περιορισμένη εκτέλεση → ασφαλής επιχειρησιακή επανάληψη → δοκιμή ανάκαμψης. «Ένα ενεργό job» δεν αποδεικνύει μία ακριβώς επιχειρησιακή επίδραση.

Περίπτωση	Επιλογή αξιολόγησης	Ευθύνη που παραμένει
Η πλατφόρμα παρέχει προγραμματισμένα jobs	Scheduling έξω από web instances	Ρύθμιση επικάλυψης, ανάκτησης και χαμένων εκτελέσεων.
Η ομάδα λειτουργεί ήδη BullMQ	Κοινός Job Scheduler και ειδική ουρά	Κοινός παραλληλισμός και ασφαλείς επαναλήψεις.
Η εργασία πρέπει να μείνει στους κόμβους	Κοινό lock ή lease	Σωστή κυριότητα, λήξη και παλιοί workers.

1. Καταλάβετε γιατί ξεκινούν όλοι οι κόμβοι

2. Επιλέξτε μοντέλο συντονισμού

3. Προστατεύστε το τιμολόγιο, όχι μόνο το job

4. Γνωρίστε τα όρια του lock

5. Ελέγξτε αποτυχίες

Σχετικές ερωτήσεις