Miben különbözik az EventEmitter a Node.js-feladatsortól?

Question

IT Interview Practice · Accepted Answer

Az EventEmitter és a feladatsor között azt kérdezve válassz, **hol kell futnia a munkának, és mi történik a folyamat leállásakor**.

Az EventEmitter egy Node.js-folyamaton belüli figyelőket értesít. A tartós sor későbbi workerfeldolgozásra tárol munkát. Mindkettő szétválasztja a felelősségeket, de másképp viselkedik hibánál.

## 1. Kövesd a helyi értesítést

Tegyük fel, egy komponens befejezi az inicializálást, és ugyanazon folyamat más komponenseinek reagálniuk kell. Az EventEmitter természetes választás: regisztráld a figyelőket, majd bocsásd ki az eseményt.

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

A Node.js a regisztráció sorrendjében, szinkron módon hívja a figyelőket. Az esemény nem marad meg később regisztrálóknak, a befejezetlen munka pedig nem éli túl az összeomlást. [Node.js Events](https://nodejs.org/api/events.html).

Ez megfelelő helyi, elveszíthető vagy újraalkotható értesítéshez. Nem elég, ha az üzlet a küldő leállásán túl is megköveteli a munkát.

## 2. Értsd meg az async figyelő hatását

Az async figyelő indíthat aszinkron munkát, de az emit nem várja a visszaadott promise-t. A hívási és befejezési sorrend ezért eltérhet.

A figyelő CPU-igényes szinkron kódja továbbra is feltartja a folyamatot. Kezeld a kivételeket és elutasított promise-okat; a captureRejections hibakezeléshez irányíthatja őket, de nem tárolja vagy ismétli a feladatot.

Az async a munka végzését módosítja. A memóriabeli eseményt nem alakítja tartós sorrá.

## 3. Kövesd a sorba tett feladatot

Most a rendelés mentésének végül számlát kell létrehoznia. A sor megőrzi az utasítást, amíg a workerek hiányoznak vagy foglaltak.

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

A producer beadja a feladatot; a worker feldolgoz egy próbálkozást és rögzíti az eredményt. A workerek az API-tól külön telepíthetők és skálázhatók. A tartósság a sor tárolásától és beállításaitól függ.

Szokásos versengő workeres sorban egy próbálkozást egy worker kezel. Ez eltér minden EventEmitter-figyelő értesítésétől. Ha több független előfizetőnek kell az esemény, ilyen kézbesítési modellt válassz vagy állíts be.

## 4. Ellenőrizd a mentés és sorba adás közötti rést

EventEmitternél a rendelésmentés és emit közötti összeomlás elveszítheti a számlautasítást. A tartós sor elfogadás után védi a feladatot, de az adatbázis-commit és beadás közötti korábbi rést nem zárja automatikusan.

Az outbox a rendelést és utasítását azonos tranzakcióban tárolva zárja a rést. A továbbító később olvassa és küldi a feladatot.

Ha elveszik a visszaigazolás, a kézbesítés ismétlődhet. A számlakészítéshez stabil üzleti kulcs és egyediségi korlát vagy más idempotens megoldás kell. Új próbálkozás ne készítsen második számlát. [Idempotens feladatok](https://docs.bullmq.io/patterns/idempotent-jobs).

## 5. A tényleges igény szerint hasonlíts össze

| Igény | EventEmitter | Tartós feladatsor |
| --- | --- | --- |
| Egy folyamat komponenseinek értesítése | Közvetlen és könnyű | Többnyire felesleges infrastruktúrát ad. |
| Munka megőrzése a küldő leállása után | Nincs beépített tartós rekord | Megfelelő tárolással és helyreállítással lehetséges. |
| Újrapróbálás és hátralék vizsgálata | Az alkalmazásnak kell megépítenie | Gyakori sorfunkciók, megfelelő beállítással. |
| Más gépen végzett munka | Nem erre való | A workerek önállóan futnak. |

Inicializáláshoz EventEmittert használnék. Hibából helyreálló számlázáshoz tartós sort, rendezett adatbázis-átadással és ismétléskezeléssel.

Fontos határokon állítsd le a folyamatot: beadás előtt, elfogadás után és az üzleti hatás után. Az eredmény feleljen meg a felhasználó által várt garanciának.

**Emlékezz:** helyi értesítés → EventEmitter; helyreállítható háttérmunka → tartós sor. Kritikus hatásnál az átadást és idempotenciát is tervezd meg.

Igény	EventEmitter	Tartós feladatsor
Egy folyamat komponenseinek értesítése	Közvetlen és könnyű	Többnyire felesleges infrastruktúrát ad.
Munka megőrzése a küldő leállása után	Nincs beépített tartós rekord	Megfelelő tárolással és helyreállítással lehetséges.
Újrapróbálás és hátralék vizsgálata	Az alkalmazásnak kell megépítenie	Gyakori sorfunkciók, megfelelő beállítással.
Más gépen végzett munka	Nem erre való	A workerek önállóan futnak.

1. Kövesd a helyi értesítést

2. Értsd meg az async figyelő hatását

3. Kövesd a sorba tett feladatot

4. Ellenőrizd a mentés és sorba adás közötti rést

5. A tényleges igény szerint hasonlíts össze

Kapcsolódó kérdések