რით განსხვავდება EventEmitter დავალებათა რიგისგან Node.js-ში?

Question

IT Interview Practice · Accepted Answer

EventEmitter-სა და დავალებების რიგს შორის არჩევისას იკითხეთ: **სად უნდა შესრულდეს სამუშაო და რა მოხდება პროცესის გაჩერებისას**.

EventEmitter ერთ Node.js პროცესში მსმენელებს ატყობინებს. გამძლე რიგი სამუშაოს მოგვიანებით მუშაკების მიერ დასამუშავებლად ინახავს. ორივე პასუხისმგებლობებს ყოფს, მაგრამ მარცხისას მათი ქცევა განსხვავდება.

## 1. მიჰყევით ლოკალურ შეტყობინებას

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

```text
[One process]
emit("ready") -> Listener A
              -> Listener B
```

Node.js მსმენელებს სინქრონულად, რეგისტრაციის თანმიმდევრობით იძახებს. მოვლენა მოგვიანებით რეგისტრირებული მსმენელებისთვის არ ინახება და დაუმთავრებელი სამუშაო პროცესის ავარიას ვერ გადაურჩება. [Node.js Events](https://nodejs.org/api/events.html).

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

## 2. გაიგეთ async მსმენელის გავლენა

Async მსმენელს ასინქრონული სამუშაოს დაწყება შეუძლია, მაგრამ emit დაბრუნებულ promise-ს არ ელოდება. ამიტომ გამოძახების რიგი დასრულების რიგს აუცილებლობით არ ემთხვევა.

მსმენელში CPU-ზე მძიმე სინქრონული კოდი პროცესს მაინც აყოვნებს. გამონაკლისები და უარყოფილი promise-ები მიზანმიმართულად მართეთ; captureRejections უარყოფას შეცდომის დამუშავებაში გზავნის, მაგრამ დავალებას არ ინახავს და არ იმეორებს.

Async მსმენელის მუშაობის წესს ცვლის. მეხსიერებაში მყოფ მოვლენას გამძლე რიგად არ აქცევს.

## 3. მიჰყევით რიგში ჩასმულ დავალებას

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

```text
[Producer] -> [Durable queue] -> [Available worker]
                    |                   |
              [Pending work]      [Result / retry]
```

გამგზავნი დავალებას ამატებს; მუშაკი მცდელობას ასრულებს და შედეგს წერს. მუშაკები API-სგან დამოუკიდებლად შეიძლება განთავსდეს და გაიზარდოს. გამძლეობა მაინც რიგის საცავსა და კონფიგურაციაზეა დამოკიდებული.

ტიპურ კონკურენტ მუშაკთა რიგში თითო მცდელობას ერთი მუშაკი ამუშავებს. ეს EventEmitter-ის ყველა მსმენელთან გავრცელებისგან განსხვავდება. თუ რამდენიმე დამოუკიდებელ გამომწერს თითოეულს მოვლენა სჭირდება, შესაბამისი მიწოდების მოდელი აირჩიეთ ან დააკონფიგურირეთ.

## 4. შეამოწმეთ შენახვასა და რიგში გაგზავნას შორის შუალედი

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

Outbox ამ შუალედს შეკვეთისა და ინსტრუქციის ერთ ტრანზაქციაში შენახვით ხურავს. გამომქვეყნებელი outbox-ს კითხულობს და დავალებას შემდეგ აგზავნის.

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

## 5. ვარიანტები რეალურ საჭიროებას შეადარეთ

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

ინიციალიზაციისთვის EventEmitter-ს გამოვიყენებდი. მარცხის შემდეგ აღსადგენი ინვოისისთვის — გამძლე რიგს, ბაზიდან გადაცემისა და განმეორებული მცდელობების მართვით.

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

**დაიმახსოვრეთ:** ლოკალური შეტყობინება → EventEmitter; აღდგენადი ფონური სამუშაო → გამძლე რიგი. კრიტიკული ეფექტებისთვის გადაცემა და იდემპოტენტურობაც დაგეგმეთ.

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

1. მიჰყევით ლოკალურ შეტყობინებას

2. გაიგეთ async მსმენელის გავლენა

3. მიჰყევით რიგში ჩასმულ დავალებას

4. შეამოწმეთ შენახვასა და რიგში გაგზავნას შორის შუალედი

5. ვარიანტები რეალურ საჭიროებას შეადარეთ

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