Velg mellom EventEmitter og jobbkø ved å spørre hvor arbeidet skal kjøre, og hva som skjer hvis prosessen stopper.
EventEmitter varsler lyttere i én Node.js-prosess. En varig kø lagrer arbeid som workers behandler senere. Begge skiller ansvar, men oppfører seg ulikt ved feil.
Anta at en komponent er ferdig med initialisering og vil at andre komponenter i samme prosess skal reagere. EventEmitter passer naturlig: registrer lyttere og send deretter hendelsen.
[One process]
emit("ready") -> Listener A
-> Listener B
Node.js kaller registrerte lyttere synkront i registreringsrekkefølge. Selve hendelsen lagres ikke for lyttere som registreres senere, og uferdig arbeid overlever ikke et prosesskrasj. Node.js Events.
Dette fungerer når varselet er lokalt og kan mistes eller gjenskapes. Det er utilstrekkelig når virksomheten forventer at arbeidet overlever avsenderen.
En async-lytter kan starte asynkront arbeid, men emit venter ikke på den returnerte promisen. Kallrekkefølge er derfor ikke nødvendigvis fullføringsrekkefølge.
CPU-tung synkron kode i lytteren forsinker fortsatt prosessen. Håndter kastede feil og avviste promises bevisst; captureRejections kan sende avvisninger til feilhåndtering, men lagrer ikke oppgaven eller prøver den på nytt.
Async endrer hvordan lytteren arbeider. Det gjør ikke en hendelse i minnet til en varig kø.
Anta nå at lagring av en ordre til slutt må generere en faktura. En kø gir et sted å beholde instruksen mens workers er utilgjengelige eller opptatt.
[Producer] -> [Durable queue] -> [Available worker]
| |
[Pending work] [Result / retry]
Produsenten sender en jobb; en worker behandler et forsøk og lagrer resultatet. Workers kan utrulles og skaleres separat fra API-et. Varigheten avhenger fortsatt av køens lagring og konfigurasjon.
I en vanlig kø med konkurrerende workers håndterer én worker hvert forsøk. Dette er annerledes enn å sende hendelsen til alle EventEmitter-lyttere. Hvis flere uavhengige abonnenter hver trenger hendelsen, må leveringsmodellen støtte det.
Med EventEmitter kan et krasj etter lagring av ordren, men før utsending, miste fakturainstruksen. En varig kø beskytter jobben etter at den er godtatt, men beskytter ikke automatisk det tidligere gapet mellom databasecommit og innsending.
En outbox lukker gapet ved å lagre ordren og instruksen i samme databasetransaksjon. En publisher leser outboxen og sender jobben senere.
Levering kan gjentas hvis publisheren mister bekreftelsen. Gi fakturaoppretting en stabil forretningsnøkkel og unikhetsbegrensning eller annen idempotent implementasjon. Et gjentatt forsøk skal ikke lage faktura nummer to. Idempotente jobber.
| Krav | EventEmitter | Varig jobbkø |
|---|---|---|
| Varsle komponenter i én prosess | Direkte og lettvekts | Gir vanligvis unødvendig infrastruktur. |
| Beholde ventende arbeid etter at avsender stopper | Ingen innebygd varig post | Mulig med egnet lagring og gjenoppretting. |
| Prøve igjen og undersøke etterslep | Applikasjonen må bygge dette | Vanlige køfunksjoner, med konfigurasjon. |
| Kjøre arbeid på andre maskiner | Ikke dens rolle | Workers kan kjøre uavhengig. |
For initialisering ville jeg brukt EventEmitter. For fakturering som må tåle feil, ville jeg brukt en varig kø og håndtert overlevering fra databasen og dupliserte forsøk.
Test ved å stoppe prosessen ved viktige grenser: før innsending, etter aksept og etter forretningseffekten. Resultatet skal stemme med garantien brukeren forventer.
Husk: lokalt varsel → EventEmitter; gjenopprettbart bakgrunnsarbeid → varig kø. For kritiske effekter må også overlevering og idempotens utformes.
Et bibliotek av IT-intervjuspørsmål med detaljerte svar — fra Junior til Senior.
Doner