როგორ ვმართოთ cron დავალება რამდენიმე NestJS კვანძზე?

Question

IT Interview Practice · Accepted Answer

ჯერ განსაზღვრეთ, რას ნიშნავს „cronjob-ს მხოლოდ ერთი კვანძი ასრულებს“. **ერთდროული გაშვების აკრძალვა და ბიზნესეფექტის გამეორების აკრძალვა სხვადასხვა მოთხოვნაა.** საერთო დამგეგმავი შესრულებას ათანხმებს; ოპერაცია ავარიისა და განმეორების შემდეგაც უსაფრთხო უნდა იყოს.

განვიხილოთ ყოველდღიური ინვოისების დავალება სამ NestJS კვანძზე. გვინდა დაგეგმილი სამუშაო შესრულდეს ისე, რომ მუშაკის გადატვირთვამ დამატებითი ინვოისი არ შექმნას.

## 1. გაიგეთ, რატომ იწყებს ყველა კვანძი დავალებას

აპლიკაციის თითოეული ეგზემპლარი საკუთარ cron callback-ს არეგისტრირებს. დაგეგმილ დროს თითოეული დამოუკიდებლად შეიძლება დაიწყოს:

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

ლოკალური isRunning ალამი მხოლოდ ერთ პროცესში არსებობს. NestJS-ის waitForCompletion იმავე ეგზემპლარში გადაფარულ callback-ებს აჩერებს, მაგრამ სხვა კვანძებს არ ათანხმებს. სამივეზე ერთნაირი ალამიც სამ დამოუკიდებელ გადაწყვეტილებას ტოვებს. [NestJS-ის დაგეგმვა](https://docs.nestjs.com/techniques/task-scheduling).

ამიტომ საჭიროა საერთო ადგილი, რომელიც გადაწყვეტს, რა სამუშაო არსებობს და ვის შეუძლია მისი შესრულება.

## 2. აირჩიეთ კოორდინაციის მოდელი

| ვითარება | შესაფასებელი ვარიანტი | დარჩენილი პასუხისმგებლობა |
| --- | --- | --- |
| პლატფორმას უკვე აქვს დაგეგმილი დავალებები | დაგეგმვა ვებეგზემპლარების გარეთ | გადაფარვის, აღდგენისა და გამოტოვებული გაშვების ქცევის მართვა. |
| გუნდი უკვე იყენებს BullMQ-ს | საერთო Job Scheduler და გამოყოფილი რიგი | საერთო კონკურენტულობისა და უსაფრთხო გამეორების მართვა. |
| დავალება აპლიკაციის კვანძებზე უნდა დარჩეს | საერთო lock ან lease | მფლობელობის, ვადის გასვლისა და მოძველებული მუშაკების სწორი მართვა. |

თუ Redis და BullMQ უკვე არსებობს, ინვოისებისთვის სტაბილური ID-ის მქონე საერთო დამგეგმავი პრაქტიკული ვარიანტია. გრაფიკი მუშაკებისგან გამოყავით, რათა ვებკვანძების დამატებამ დამოუკიდებელი გრაფიკები არ შექმნას.

მხარდაჭერილ BullMQ ვერსიაში გამოყოფილი რიგის გლობალური კონკურენტულობა ერთზე დააყენეთ. ეს ყველა მუშაკში აქტიურ დავალებებს ზღუდავს; თითო მუშაკზე ლოკალური ზღვარი ერთი მაინც უშვებს რამდენიმე მუშაკზე სხვადასხვა დავალების შესრულებას. [გლობალური კონკურენტულობა](https://docs.bullmq.io/guide/queues/global-concurrency).

გადაწყვიტეთ, რა მოხდება, თუ გუშინდელი სამუშაო ჯერ არ დასრულებულა: ლოდინი, გამოტოვება თუ გაერთიანება. განსაზღვრეთ დროის სარტყელი და გათიშვისას გამოტოვებული ბიზნესთარიღების დამუშავება.

## 3. დაიცავით ინვოისი და არა მხოლოდ დავალება

დავუშვათ, მუშაკმა ინვოისი შექმნა და დასრულების ჩაწერამდე გაითიშა. აღდგენისას დავალება შეიძლება განმეორდეს, მიუხედავად უკვე არსებული ინვოისისა.

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

გამოიყენეთ სტაბილური ბიზნესგასაღები, მაგალითად, მომხმარებელი და საანგარიშო პერიოდი. ლოკალურ ბაზაში უნიკალურობის შეზღუდვა და ტრანზაქცია ინვოისის შექმნას შესრულების ჩანაწერს დაუკავშირებს. განმეორება არსებულ შედეგს იპოვის და ახალ ინვოისს არ შექმნის.

გარე პროვაიდერთან გამოიყენეთ იდემპოტენტურობის გასაღები, თუ მხარდაჭერილია, და გაურკვეველი შედეგები შეაჯერეთ. რიგის დავალების ID ან შენახული ჩანაწერი თავისთავად მუდმივი გარანტია არ არის, რომ ბიზნესმოქმედება არ განმეორდება. [იდემპოტენტური დავალებები](https://docs.bullmq.io/patterns/idempotent-jobs).

## 4. იცოდეთ lock-ის შესაძლებლობები და საზღვრები

საერთო lock ატომურად უნდა აიღოთ. გამოიყენეთ მფლობელობის ტოკენი, ვადა და განახლება; გაუშვით მხოლოდ მაშინ, თუ ტოკენი კვლავ ემთხვევა. სხვაგვარად ძველმა მუშაკმა ახლის lock შეიძლება გაათავისუფლოს.

ვადის გასვლა ახალ შემთხვევას ქმნის: შეჩერებული მუშაკი lease-ის გასვლის შემდეგ ბრუნდება, როცა ახალი უკვე მუშაობს. კრიტიკულ ჩაწერებს შეიძლება fencing token დასჭირდეს — მზარდი მფლობელობის ნომერი, რომელსაც მიმღები ამოწმებს და ძველ მუშაკს უარყოფს. მხოლოდ ხანგრძლივი timeout ამ რისკს ვერ აქრობს.

თუ კოორდინაცია მიუწვდომელია, გადაწყვიტეთ, სჯობს თუ არა მფლობელობის გარეშე გაშვებას ლოდინი. მნიშვნელოვანი შედეგების მქონე სამუშაოსთვის ლოდინი ხშირად უსაფრთხოა.

## 5. შეამოწმეთ მარცხის შემთხვევები

გამოსცადეთ რამდენიმე კვანძი, ავარია ინვოისის შექმნის შემდეგ, lease-ზე ხანგრძლივი პაუზა, Redis-თან კავშირის დაკარგვა და ეტაპობრივი განთავსება. ჩაიწერეთ ბიზნესთარიღი, მუშაკი, მცდელობა და შედეგი, რათა განმეორებული მცდელობა განმეორებული ეფექტისგან გაარჩიოთ.

**დაიმახსოვრეთ:** გრაფიკის შეთანხმება → საერთო შესრულების შეზღუდვა → ბიზნესმოქმედების უსაფრთხო გამეორება → აღდგენის გამოცდა. „ერთი აქტიური დავალება“ ზუსტად ერთ ბიზნესეფექტს არ ამტკიცებს.

ვითარება	შესაფასებელი ვარიანტი	დარჩენილი პასუხისმგებლობა
პლატფორმას უკვე აქვს დაგეგმილი დავალებები	დაგეგმვა ვებეგზემპლარების გარეთ	გადაფარვის, აღდგენისა და გამოტოვებული გაშვების ქცევის მართვა.
გუნდი უკვე იყენებს BullMQ-ს	საერთო Job Scheduler და გამოყოფილი რიგი	საერთო კონკურენტულობისა და უსაფრთხო გამეორების მართვა.
დავალება აპლიკაციის კვანძებზე უნდა დარჩეს	საერთო lock ან lease	მფლობელობის, ვადის გასვლისა და მოძველებული მუშაკების სწორი მართვა.

1. გაიგეთ, რატომ იწყებს ყველა კვანძი დავალებას

2. აირჩიეთ კოორდინაციის მოდელი

3. დაიცავით ინვოისი და არა მხოლოდ დავალება

4. იცოდეთ lock-ის შესაძლებლობები და საზღვრები

5. შეამოწმეთ მარცხის შემთხვევები

დაკავშირებული კითხვები