Hur skiljer sig EventEmitter från en jobbkö i Node.js?

Question

IT Interview Practice · Accepted Answer

Välj mellan EventEmitter och en jobbkö genom att fråga **var arbetet måste köras och vad som händer om processen stannar**.

EventEmitter meddelar lyssnare i en Node.js-process. En beständig kö lagrar arbete som workers bearbetar senare. Båda separerar ansvar, men beter sig olika vid fel.

## 1. Följ en lokal avisering

Anta att en komponent är färdiginitialiserad och vill att andra komponenter i samma process reagerar. EventEmitter passar naturligt: registrera lyssnare och sänd sedan händelsen.

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

Node.js anropar registrerade lyssnare synkront i registreringsordning. Händelsen sparas inte för lyssnare som registreras senare, och oavslutat arbete överlever inte en processkrasch. [Node.js Events](https://nodejs.org/api/events.html).

Det fungerar när aviseringen är lokal och får förloras eller kan återskapas. Det räcker inte när verksamheten förväntar sig att arbetet överlever avsändaren.

## 2. Förstå vad en async-lyssnare ändrar

En async-lyssnare kan starta asynkront arbete, men emit väntar inte på dess returnerade promise. Anropsordningen är därför inte nödvändigtvis slutförandeordningen.

CPU-tung synkron kod i lyssnaren fördröjer fortfarande processen. Hantera kastade fel och avvisade promises medvetet; captureRejections kan styra avvisningar till felhantering, men sparar inte uppgiften beständigt och försöker inte igen.

Att lägga till async ändrar hur lyssnaren arbetar. Det gör inte en händelse i minnet till en beständig kö.

## 3. Följ en köad uppgift

Anta nu att en sparad order så småningom måste ge en faktura. En kö ger en plats för instruktionen medan workers är upptagna eller otillgängliga.

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

Producenten skickar ett jobb; en worker bearbetar ett försök och registrerar resultatet. Workers kan driftsättas och skalas separat från API:t. Beständigheten beror fortfarande på köns lagring och konfiguration.

I en typisk kö med konkurrerande workers hanterar en worker varje försök. Det skiljer sig från att skicka en händelse till alla EventEmitter-lyssnare. Om flera oberoende prenumeranter behöver händelsen var för sig måste leveransmodellen väljas eller konfigureras för det.

## 4. Kontrollera glappet mellan att spara och köa

Med EventEmitter kan en krasch efter att ordern sparats men före händelsen tappa faktureringsinstruktionen. En beständig kö skyddar jobbet efter att det accepterats, men skyddar inte automatiskt det tidigare glappet mellan databasens commit och inlämningen.

En outbox stänger glappet genom att spara ordern och dess instruktion i samma databastransaktion. En publicerare läser outboxen och skickar jobbet senare.

Leveransen kan upprepas om publiceraren förlorar bekräftelsen. Ge fakturaskapandet en stabil verksamhetsnyckel och en unikhetsbegränsning eller annan idempotent implementation. Ett nytt försök ska inte skapa en andra faktura. [Idempotenta jobb](https://docs.bullmq.io/patterns/idempotent-jobs).

## 5. Jämför alternativen mot det faktiska behovet

| Krav | EventEmitter | Beständig jobbkö |
| --- | --- | --- |
| Meddela komponenter i en process | Direkt och lättviktigt | Ger oftast onödig infrastruktur. |
| Behålla väntande arbete efter att avsändaren stannat | Ingen inbyggd beständig post | Möjligt med lämplig lagring och återställning. |
| Försöka igen och granska väntande arbete | Applikationen måste bygga detta | Vanliga köfunktioner, med konfiguration. |
| Köra arbete på andra maskiner | Inte dess roll | Workers kan köras oberoende. |

För initialiseringsexemplet skulle jag använda EventEmitter. För fakturering som måste återhämta sig från fel skulle jag använda en beständig kö och hantera överlämningen från databasen samt upprepade försök.

Testa genom att stoppa processen vid viktiga gränser: före inlämning, efter acceptans och efter verksamhetseffekten. Resultatet ska motsvara garantin användaren förväntar sig.

**Kom ihåg:** lokal avisering → EventEmitter; återställbart bakgrundsarbete → beständig kö. För kritiska effekter måste även överlämning och idempotens utformas.

Krav	EventEmitter	Beständig jobbkö
Meddela komponenter i en process	Direkt och lättviktigt	Ger oftast onödig infrastruktur.
Behålla väntande arbete efter att avsändaren stannat	Ingen inbyggd beständig post	Möjligt med lämplig lagring och återställning.
Försöka igen och granska väntande arbete	Applikationen måste bygga detta	Vanliga köfunktioner, med konfiguration.
Köra arbete på andra maskiner	Inte dess roll	Workers kan köras oberoende.

1. Följ en lokal avisering

2. Förstå vad en async-lyssnare ändrar

3. Följ en köad uppgift

4. Kontrollera glappet mellan att spara och köa

5. Jämför alternativen mot det faktiska behovet

Relaterade frågor