Si ndryshon EventEmitter nga një radhë job-esh në Node.js?

Question

IT Interview Practice · Accepted Answer

Zgjidhni mes EventEmitter dhe një radhe punësh duke pyetur **ku duhet të ekzekutohet puna dhe çfarë ndodh nëse procesi ndalon**.

EventEmitter njofton dëgjues brenda një procesi Node.js. Një radhë e qëndrueshme ruan punën për përpunim të mëvonshëm nga worker-at. Të dyja ndajnë përgjegjësitë, por kanë sjellje të ndryshme në dështim.

## 1. Ndiqni një njoftim lokal

Supozoni se një komponent përfundon inicializimin dhe dëshiron që komponentë të tjerë në të njëjtin proces të reagojnë. EventEmitter përshtatet natyrshëm: regjistroni dëgjuesit, pastaj emetoni ngjarjen.

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

Node.js i thërret dëgjuesit e regjistruar në mënyrë sinkrone sipas rendit të regjistrimit. Vetë ngjarja nuk ruhet për dëgjues që regjistrohen më vonë, dhe puna e papërfunduar nuk mbijeton pas rrëzimit të procesit. [Ngjarjet në Node.js](https://nodejs.org/api/events.html).

Kjo funksionon kur njoftimi është lokal dhe mund të humbasë ose rindërtohet. Bëhet e pamjaftueshme kur biznesi pret që puna t’i mbijetojë dërguesit.

## 2. Kuptoni çfarë ndryshon dëgjuesi async

Një dëgjues async mund të nisë punë asinkrone, por emit nuk pret promise-in që ai kthen. Prandaj rendi i thirrjes nuk është domosdoshmërisht rendi i përfundimit.

Kodi sinkron me përdorim të rëndë CPU brenda dëgjuesit ende e vonon procesin. Trajtoni me qëllim gabimet e hedhura dhe promise-et e refuzuara; captureRejections mund t’i drejtojë refuzimet te trajtimi i gabimeve, por nuk e ruan detyrën në mënyrë të qëndrueshme dhe nuk e riprovon.

Shtimi i async ndryshon mënyrën si dëgjuesi punon. Nuk e kthen një ngjarje në memorie në radhë të qëndrueshme.

## 3. Ndiqni një detyrë në radhë

Tani supozoni se ruajtja e një porosie duhet përfundimisht të gjenerojë faturë. Radha siguron një vend ku udhëzimi qëndron kur worker-at nuk janë të disponueshëm ose janë të zënë.

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

Prodhuesi dërgon një punë; një worker përpunon një përpjekje dhe regjistron rezultatin. Worker-at mund të vendosen dhe shkallëzohen veçmas nga API-ja. Qëndrueshmëria ende varet nga ruajtja dhe konfigurimi i radhës.

Në një radhë tipike me worker-a që konkurrojnë, një worker trajton çdo përpjekje. Kjo ndryshon nga transmetimi i ngjarjes te çdo dëgjues EventEmitter. Nëse secili nga disa abonentë të pavarur e kërkon ngjarjen, zgjidhni ose konfiguroni një model dërgimi që e mbështet këtë kërkesë.

## 4. Kontrolloni boshllëkun mes ruajtjes dhe futjes në radhë

Me EventEmitter, ndërprerja pas ruajtjes së porosisë por përpara emetimit mund ta humbasë udhëzimin e faturës. Radha e qëndrueshme mbron një punë pasi e pranon, por nuk mbron automatikisht boshllëkun e mëparshëm mes commit-it të databazës dhe dërgimit.

Outbox e mbyll këtë boshllëk duke ruajtur porosinë dhe udhëzimin e saj në të njëjtin transaksion databaze. Një publikues lexon outbox-in dhe e dërgon punën më vonë.

Dërgimi mund të përsëritet nëse publikuesi humbet konfirmimin. Jepini krijimit të faturës çelës biznesi të qëndrueshëm dhe kufizim uniciteti ose zbatim tjetër idempotent. Përsëritja e përpjekjes nuk duhet të krijojë faturë të dytë. [Punë idempotente](https://docs.bullmq.io/patterns/idempotent-jobs).

## 5. Krahasoni mundësitë sipas nevojës reale

| Kërkesa | EventEmitter | Radhë e qëndrueshme punësh |
| --- | --- | --- |
| Njoftim i komponentëve në një proces | I drejtpërdrejtë dhe i lehtë | Zakonisht shton infrastrukturë të panevojshme. |
| Mbajtje e punës në pritje pasi dërguesi ndalon | Nuk ka regjistrim të qëndrueshëm të integruar | E mundur me ruajtje dhe rikuperim të përshtatshëm. |
| Riprovim dhe kontroll i punës së grumbulluar | Aplikacioni duhet ta ndërtojë | Aftësi të zakonshme radhësh, me konfigurim. |
| Ekzekutim në makina të tjera | Nuk është roli i tij | Worker-at mund të punojnë në mënyrë të pavarur. |

Për shembullin e inicializimit, do të përdorja EventEmitter. Për faturimin që duhet të rikuperohet nga dështimi, do të përdorja radhë të qëndrueshme dhe do të trajtoja dorëzimin nga databaza dhe përpjekjet e dyfishta.

Testoni duke ndaluar procesin në kufijtë e rëndësishëm: përpara dërgimit, pas pranimit dhe pas efektit të biznesit. Rezultati duhet të përputhet me garancinë që pret përdoruesi.

**Mbani mend:** njoftim lokal → EventEmitter; punë në sfond që rikuperohet → radhë e qëndrueshme. Për efekte kritike, projektoni edhe dorëzimin dhe idempotencën.

Kërkesa	EventEmitter	Radhë e qëndrueshme punësh
Njoftim i komponentëve në një proces	I drejtpërdrejtë dhe i lehtë	Zakonisht shton infrastrukturë të panevojshme.
Mbajtje e punës në pritje pasi dërguesi ndalon	Nuk ka regjistrim të qëndrueshëm të integruar	E mundur me ruajtje dhe rikuperim të përshtatshëm.
Riprovim dhe kontroll i punës së grumbulluar	Aplikacioni duhet ta ndërtojë	Aftësi të zakonshme radhësh, me konfigurim.
Ekzekutim në makina të tjera	Nuk është roli i tij	Worker-at mund të punojnë në mënyrë të pavarur.

1. Ndiqni një njoftim lokal

2. Kuptoni çfarë ndryshon dëgjuesi async

3. Ndiqni një detyrë në radhë

4. Kontrolloni boshllëkun mes ruajtjes dhe futjes në radhë

5. Krahasoni mundësitë sipas nevojës reale

Pyetje të ngjashme