Hvordan adskiller EventEmitter sig fra en jobkø i Node.js?

Question

IT Interview Practice · Accepted Answer

Vælg mellem EventEmitter og en jobkø ved at spørge **hvor arbejdet skal køre, og hvad der sker, hvis processen stopper**.

EventEmitter underretter listeners i én Node.js-proces. En varig kø gemmer arbejde til senere behandling af workers. Begge adskiller ansvar, men deres fejladfærd er forskellig.

## 1. Følg en lokal besked

En komponent afslutter eksempelvis initialisering og vil have andre komponenter i samme proces til at reagere. EventEmitter passer naturligt: registrér listeners, og udsend hændelsen.

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

Node.js kalder registrerede listeners synkront i registreringsrækkefølge. Hændelsen gemmes ikke til listeners, som tilmelder sig senere, og ufærdigt arbejde overlever ikke et procesnedbrud. [Node.js Events](https://nodejs.org/api/events.html).

Det fungerer, når beskeden er lokal og må mistes eller rekonstrueres. Det er utilstrækkeligt, når arbejdet skal overleve afsenderen.

## 2. Forstå ændringen med en async listener

En async listener kan starte asynkront arbejde, men emit venter ikke på dens returnerede promise. Kalderækkefølge er derfor ikke nødvendigvis afslutningsrækkefølge.

CPU-tung synkron kode i listeneren forsinker stadig processen. Håndtér kastede fejl og afviste promises bevidst; captureRejections kan sende afvisninger til fejlhåndtering, men gemmer eller gentager ikke opgaven.

Async ændrer listenerens arbejdsform. Det gør ikke en hændelse i hukommelsen til en varig kø.

## 3. Følg en opgave i kø

Antag nu, at lagring af en ordre til sidst skal skabe en faktura. Køen holder instruktionen, mens workers er utilgængelige eller optagede.

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

Producenten indsender et job; en worker behandler et forsøg og registrerer resultatet. Workers kan udrulles og skaleres uafhængigt af API'et. Holdbarheden afhænger stadig af køens lager og konfiguration.

I en typisk kø med konkurrerende workers håndterer én worker hvert forsøg. Det adskiller sig fra udsendelse til alle EventEmitter-listeners. Hvis flere uafhængige abonnenter hver skal modtage hændelsen, skal leveringsmodellen understøtte dette.

## 4. Kontrollér hullet mellem lagring og kø

Med EventEmitter kan et nedbrud efter ordrelagring, men før emit, miste fakturainstruktionen. En varig kø beskytter jobbet efter accept, men beskytter ikke automatisk det tidligere hul mellem databasecommit og indsendelse.

En outbox lukker hullet ved at gemme ordre og instruktion i samme databasetransaktion. En publisher læser outbox og sender jobbet senere.

Levering kan gentages, hvis publisheren mister bekræftelsen. Giv fakturaskabelsen en stabil forretningsnøgle og en unik constraint eller anden idempotent implementering. Gentagelse må ikke skabe en ekstra faktura. [Idempotente job](https://docs.bullmq.io/patterns/idempotent-jobs).

## 5. Sammenlign med det faktiske behov

| Krav | EventEmitter | Varig jobkø |
| --- | --- | --- |
| Underret komponenter i én proces | Direkte og let | Tilføjer normalt unødig infrastruktur. |
| Bevar ventende arbejde efter afsenderstop | Intet indbygget varigt register | Muligt med korrekt lager og gendannelse. |
| Gentag og undersøg ophobet arbejde | Skal bygges i applikationen | Almindelige køfunktioner med konfiguration. |
| Udfør arbejde på andre maskiner | Ikke dens rolle | Workers kan køre uafhængigt. |

Til initialisering ville jeg bruge EventEmitter. Til fakturering, som skal genoprettes efter fejl, ville jeg bruge en varig kø og løse databaseoverdragelsen og gentagne forsøg.

Test ved at stoppe processen ved vigtige grænser: før indsendelse, efter accept og efter forretningseffekten. Resultatet skal svare til brugerens forventede garanti.

**Husk:** lokal besked → EventEmitter; gendanneligt baggrundsarbejde → varig kø. Design også overdragelse og idempotens ved kritiske effekter.

Krav	EventEmitter	Varig jobkø
Underret komponenter i én proces	Direkte og let	Tilføjer normalt unødig infrastruktur.
Bevar ventende arbejde efter afsenderstop	Intet indbygget varigt register	Muligt med korrekt lager og gendannelse.
Gentag og undersøg ophobet arbejde	Skal bygges i applikationen	Almindelige køfunktioner med konfiguration.
Udfør arbejde på andre maskiner	Ikke dens rolle	Workers kan køre uafhængigt.

1. Følg en lokal besked

2. Forstå ændringen med en async listener

3. Følg en opgave i kø

4. Kontrollér hullet mellem lagring og kø

5. Sammenlign med det faktiske behov

Relaterede spørgsmål