Cum diferă EventEmitter de o coadă de joburi în Node.js?

Question

IT Interview Practice · Accepted Answer

Alege între EventEmitter și o coadă de joburi întrebând **unde trebuie să ruleze munca și ce se întâmplă dacă procesul se oprește**.

EventEmitter notifică ascultătorii dintr-un singur proces Node.js. O coadă durabilă păstrează munca pentru procesarea ulterioară de către workeri. Ambele separă responsabilități, însă comportamentul la eșec diferă.

## 1. Urmărește o notificare locală

Să presupunem că o componentă termină inițializarea și dorește reacția altor componente din același proces. EventEmitter se potrivește natural: înregistrezi ascultătorii, apoi emiți evenimentul.

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

Node.js apelează sincron ascultătorii înregistrați, în ordinea înregistrării. Evenimentul nu este păstrat pentru ascultătorii înscriși ulterior, iar munca neterminată nu supraviețuiește căderii procesului. [Evenimente Node.js](https://nodejs.org/api/events.html).

Aceasta funcționează când notificarea este locală și poate fi pierdută sau reconstruită. Devine insuficientă când afacerea cere ca munca să supraviețuiască expeditorului.

## 2. Înțelege ce schimbă un ascultător async

Un ascultător async poate începe muncă asincronă, dar emit nu așteaptă promisiunea returnată. Prin urmare, ordinea apelării nu este neapărat ordinea finalizării.

Codul sincron intensiv CPU din ascultător întârzie în continuare procesul. Gestionează explicit erorile aruncate și promisiunile respinse; captureRejections poate direcționa respingerile spre tratarea erorilor, dar nu persistă și nu reîncearcă sarcina.

Adăugarea async schimbă modul în care ascultătorul execută munca. Nu transformă evenimentul din memorie într-o coadă durabilă.

## 3. Urmărește o sarcină pusă în coadă

Acum să presupunem că salvarea unei comenzi trebuie să genereze în cele din urmă o factură. Coada oferă un loc pentru păstrarea instrucțiunii cât timp workerii sunt ocupați sau indisponibili.

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

Producătorul trimite un job; un worker procesează o încercare și înregistrează rezultatul. Workerii pot fi instalați și scalați separat de API. Durabilitatea depinde în continuare de stocarea și configurația cozii.

Într-o coadă obișnuită cu workeri concurenți, un worker gestionează fiecare încercare. Aceasta diferă de difuzarea evenimentului către toți ascultătorii EventEmitter. Dacă mai mulți abonați independenți au fiecare nevoie de eveniment, alege sau configurează un model de livrare care susține cerința.

## 4. Verifică intervalul dintre salvare și punerea în coadă

Cu EventEmitter, o cădere după salvarea comenzii, dar înainte de emitere, poate pierde instrucțiunea de facturare. O coadă durabilă protejează jobul după acceptare, însă nu protejează automat intervalul anterior dintre confirmarea tranzacției și trimitere.

Un outbox închide această fereastră salvând comanda și instrucțiunea ei în aceeași tranzacție. Un publisher citește outboxul și trimite jobul ulterior.

Livrarea se poate repeta dacă publisherul pierde confirmarea. Dă creării facturii o cheie de afaceri stabilă și o constrângere de unicitate sau altă implementare idempotentă. Repetarea încercării nu trebuie să creeze a doua factură. [Joburi idempotente](https://docs.bullmq.io/patterns/idempotent-jobs).

## 5. Compară opțiunile cu nevoia reală

| Cerință | EventEmitter | Coadă durabilă de joburi |
| --- | --- | --- |
| Notificarea componentelor dintr-un proces | Directă și ușoară | De obicei adaugă infrastructură inutilă. |
| Păstrarea muncii după oprirea expeditorului | Fără înregistrare durabilă integrată | Posibilă cu stocare și recuperare potrivite. |
| Reluări și inspectarea muncii acumulate | Aplicația trebuie să le construiască | Funcții obișnuite ale cozilor, cu configurare. |
| Execuție pe alte mașini | Nu este rolul său | Workerii pot rula independent. |

Pentru exemplul inițializării, aș folosi EventEmitter. Pentru facturarea care trebuie să se recupereze după eșec, aș folosi o coadă durabilă și aș trata transferul din baza de date și încercările duplicate.

Testează oprind procesul la limitele importante: înainte de trimitere, după acceptare și după efectul de afaceri. Rezultatul trebuie să respecte garanția așteptată de utilizator.

**De reținut:** notificare locală → EventEmitter; muncă recuperabilă în fundal → coadă durabilă. Pentru efectele critice, proiectează și transferul și idempotența.

Cerință	EventEmitter	Coadă durabilă de joburi
Notificarea componentelor dintr-un proces	Directă și ușoară	De obicei adaugă infrastructură inutilă.
Păstrarea muncii după oprirea expeditorului	Fără înregistrare durabilă integrată	Posibilă cu stocare și recuperare potrivite.
Reluări și inspectarea muncii acumulate	Aplicația trebuie să le construiască	Funcții obișnuite ale cozilor, cu configurare.
Execuție pe alte mașini	Nu este rolul său	Workerii pot rula independent.

1. Urmărește o notificare locală

2. Înțelege ce schimbă un ascultător async

3. Urmărește o sarcină pusă în coadă

4. Verifică intervalul dintre salvare și punerea în coadă

5. Compară opțiunile cu nevoia reală

Întrebări conexe