EventEmitter inatofautianaje na job queue katika Node.js?

Question

IT Interview Practice · Accepted Answer

Chagua kati ya EventEmitter na job queue kwa kuuliza **kazi inapaswa kuendeshwa wapi na nini hutokea process ikisimama**.

EventEmitter huarifu listeners ndani ya process moja ya Node.js. Queue ya kudumu huhifadhi kazi ichakatwe baadaye na workers. Zote hutenganisha majukumu, lakini tabia zake wakati wa kushindwa ni tofauti.

## 1. Fuata taarifa ya ndani

Tuseme component inamaliza initialization na inataka components nyingine katika process ileile ziitikie. EventEmitter inafaa: sajili listeners kisha emit tukio.

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

Node.js huita listeners zilizosajiliwa synchronously kwa mpangilio wa usajili. Tukio lenyewe halihifadhiwi kwa listeners watakaosajiliwa baadaye, na kazi isiyokamilika haiokoki process crash. [Node.js Events](https://nodejs.org/api/events.html).

Hii hufanya kazi taarifa ikiwa ya ndani na inaweza kupotea au kujengwa upya. Haitoshi biashara ikitarajia kazi iendelee kuishi baada ya sender kusimama.

## 2. Elewa async listener hubadilisha nini

Async listener inaweza kuanza asynchronous work, lakini emit haisubiri promise inayorudishwa. Kwa hiyo mpangilio wa kuitwa si lazima uwe mpangilio wa kumaliza.

Code ya synchronous inayotumia CPU sana ndani ya listener bado huchelewesha process. Shughulikia makosa yanayotupwa na promises zilizokataliwa kwa makusudi; captureRejections inaweza kuelekeza rejections kwenye error handling, lakini haihifadhi wala kurudia task.

Kuongeza async hubadilisha jinsi listener hufanya kazi. Hakugeuzi tukio la kwenye kumbukumbu kuwa queue ya kudumu.

## 3. Fuata kazi kwenye queue

Sasa tuseme kuhifadhi oda lazima hatimaye kutengeneze ankara. Queue hutoa mahali pa kuweka agizo workers wakiwa hawapatikani au wana shughuli.

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

Producer huwasilisha job; worker huchakata attempt na kurekodi matokeo. Workers wanaweza kudeployiwa na kuscale kando na API. Kudumu bado hutegemea hifadhi na configuration ya queue.

Katika queue ya kawaida ya workers wanaoshindana, worker mmoja hushughulikia kila attempt. Hilo hutofautiana na kutangaza tukio kwa kila EventEmitter listener. Ikiwa subscribers kadhaa huru wanahitaji tukio kila mmoja, chagua au sanidi delivery model inayokidhi hitaji hilo.

## 4. Hakiki pengo kati ya kuhifadhi na enqueue

Kwa EventEmitter, crash baada ya kuhifadhi oda lakini kabla ya emit inaweza kupoteza agizo la ankara. Queue ya kudumu hulinda job baada ya kuikubali, lakini hailindi moja kwa moja pengo la awali kati ya database commit na submission.

Outbox huziba pengo hilo kwa kuhifadhi oda na agizo lake katika database transaction ileile. Publisher husoma outbox na kutuma job baadaye.

Delivery inaweza kurudiwa publisher akipoteza uthibitisho. Ipe kutengeneza ankara business key thabiti na uniqueness constraint au utekelezaji mwingine wa idempotent. Kurudia attempt hakupaswi kutengeneza ankara ya pili. [Idempotent jobs](https://docs.bullmq.io/patterns/idempotent-jobs).

## 5. Linganisha chaguo na hitaji halisi

| Hitaji | EventEmitter | Job queue ya kudumu |
| --- | --- | --- |
| Kuarifu components katika process moja | Ya moja kwa moja na nyepesi | Kwa kawaida huongeza infrastructure isiyohitajika. |
| Kuhifadhi kazi inayosubiri sender akisimama | Hakuna rekodi ya kudumu iliyojengwa ndani | Inawezekana kwa hifadhi na urejeshaji unaofaa. |
| Kurudia na kukagua backlog | Programu lazima ijenge hili | Uwezo wa kawaida wa queue, wenye configuration. |
| Kuendesha kazi kwenye mashine nyingine | Si jukumu lake | Workers wanaweza kuendesha kwa kujitegemea. |

Kwa mfano wa initialization, ningetumia EventEmitter. Kwa kutengeneza ankara zinazopaswa kupona baada ya hitilafu, ningetumia queue ya kudumu na kushughulikia handoff ya database na attempts zinazojirudia.

Jaribu kwa kusimamisha process katika mipaka muhimu: kabla ya submission, baada ya acceptance na baada ya athari ya biashara. Matokeo yanapaswa kulingana na dhamana ambayo mtumiaji anatarajia.

**Kumbuka:** taarifa ya ndani → EventEmitter; background work inayoweza kurejeshwa → queue ya kudumu. Kwa athari muhimu, tengeneza pia handoff na idempotency.

Hitaji	EventEmitter	Job queue ya kudumu
Kuarifu components katika process moja	Ya moja kwa moja na nyepesi	Kwa kawaida huongeza infrastructure isiyohitajika.
Kuhifadhi kazi inayosubiri sender akisimama	Hakuna rekodi ya kudumu iliyojengwa ndani	Inawezekana kwa hifadhi na urejeshaji unaofaa.
Kurudia na kukagua backlog	Programu lazima ijenge hili	Uwezo wa kawaida wa queue, wenye configuration.
Kuendesha kazi kwenye mashine nyingine	Si jukumu lake	Workers wanaweza kuendesha kwa kujitegemea.

1. Fuata taarifa ya ndani

2. Elewa async listener hubadilisha nini

3. Fuata kazi kwenye queue

4. Hakiki pengo kati ya kuhifadhi na enqueue

5. Linganisha chaguo na hitaji halisi

Maswali yanayohusiana