Czym EventEmitter różni się od kolejki zadań w Node.js?

Question

IT Interview Practice · Accepted Answer

Wybierając EventEmitter lub kolejkę zadań, zapytaj, **gdzie praca ma się odbywać i co stanie się po zatrzymaniu procesu**.

EventEmitter powiadamia odbiorców w jednym procesie Node.js. Trwała kolejka zachowuje pracę do późniejszego wykonania przez workery. Oba rozwiązania oddzielają odpowiedzialności, ale inaczej reagują na awarie.

## 1. Prześledź lokalne powiadomienie

Załóżmy, że komponent zakończył inicjalizację i chce wywołać reakcję innych komponentów tego samego procesu. EventEmitter pasuje naturalnie: zarejestruj odbiorców, a następnie wyemituj zdarzenie.

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

Node.js wywołuje odbiorców synchronicznie, w kolejności rejestracji. Zdarzenie nie jest przechowywane dla później zarejestrowanych odbiorców, a niedokończona praca nie przetrwa awarii procesu. [Zdarzenia Node.js](https://nodejs.org/api/events.html).

To działa, gdy powiadomienie jest lokalne i może zginąć lub zostać odtworzone. Nie wystarcza, gdy biznes wymaga przetrwania pracy po zakończeniu nadawcy.

## 2. Zrozum zmianę wprowadzaną przez async

Odbiorca async może rozpocząć pracę asynchroniczną, ale emit nie czeka na zwróconą promise. Kolejność wywołań nie musi więc oznaczać kolejności zakończenia.

Synchroniczne obliczenia obciążające CPU nadal opóźniają proces. Świadomie obsługuj wyjątki i odrzucone promises; captureRejections może kierować odrzucenia do obsługi błędów, ale nie zapisuje ani nie ponawia zadania.

Dodanie async zmienia sposób pracy odbiorcy. Nie zamienia zdarzenia w pamięci w trwałą kolejkę.

## 3. Prześledź zadanie w kolejce

Teraz załóżmy, że zapis zamówienia musi ostatecznie utworzyć fakturę. Kolejka zapewnia miejsce na instrukcję, gdy workery są zajęte lub niedostępne.

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

Producent zgłasza zadanie; worker wykonuje próbę i zapisuje wynik. Workery można wdrażać i skalować osobno od API. Trwałość nadal zależy od magazynu i konfiguracji kolejki.

W typowej kolejce konkurujących workerów każdą próbę obsługuje jeden worker. To inne zachowanie niż rozgłoszenie zdarzenia wszystkim odbiorcom EventEmitter. Jeśli wielu niezależnych subskrybentów musi otrzymać zdarzenie, wybierz lub skonfiguruj odpowiedni model dostarczania.

## 4. Sprawdź lukę między zapisem a kolejką

Przy EventEmitter awaria po zapisaniu zamówienia, ale przed emit, może zgubić instrukcję faktury. Trwała kolejka chroni zadanie po przyjęciu, ale nie zabezpiecza automatycznie wcześniejszej luki między zatwierdzeniem transakcji a zgłoszeniem zadania.

Outbox zamyka tę lukę, zapisując zamówienie i instrukcję w jednej transakcji bazy. Publikator odczytuje outbox i wysyła zadanie później.

Dostarczenie może się powtórzyć, jeśli publikator zgubi potwierdzenie. Nadaj tworzeniu faktury stabilny klucz biznesowy i ograniczenie unikalności lub inną implementację idempotentną. Powtórzona próba nie powinna tworzyć drugiej faktury. [Zadania idempotentne](https://docs.bullmq.io/patterns/idempotent-jobs).

## 5. Porównaj z rzeczywistą potrzebą

| Wymaganie | EventEmitter | Trwała kolejka zadań |
| --- | --- | --- |
| Powiadomienie komponentów jednego procesu | Bezpośrednie i lekkie | Zwykle dodaje zbędną infrastrukturę. |
| Zachowanie pracy po zatrzymaniu nadawcy | Brak wbudowanego trwałego zapisu | Możliwe z odpowiednim magazynem i odzyskiwaniem. |
| Ponowienia i podgląd zaległości | Aplikacja musi je zbudować | Typowe funkcje kolejki wymagające konfiguracji. |
| Wykonanie na innych maszynach | Nie jest jego rolą | Workery mogą działać niezależnie. |

Dla inicjalizacji użyłbym EventEmitter. Dla faktur wymagających odzyskiwania po błędach wybrałbym trwałą kolejkę i zaprojektował przekazanie z bazy oraz obsługę duplikatów.

Testuj zatrzymanie procesu w ważnych punktach: przed zgłoszeniem, po przyjęciu i po skutku biznesowym. Wynik powinien odpowiadać gwarancji oczekiwanej przez użytkownika.

**Zapamiętaj:** lokalne powiadomienie → EventEmitter; odzyskiwalna praca w tle → trwała kolejka. Przy krytycznych skutkach zaprojektuj też przekazanie i idempotencję.

Wymaganie	EventEmitter	Trwała kolejka zadań
Powiadomienie komponentów jednego procesu	Bezpośrednie i lekkie	Zwykle dodaje zbędną infrastrukturę.
Zachowanie pracy po zatrzymaniu nadawcy	Brak wbudowanego trwałego zapisu	Możliwe z odpowiednim magazynem i odzyskiwaniem.
Ponowienia i podgląd zaległości	Aplikacja musi je zbudować	Typowe funkcje kolejki wymagające konfiguracji.
Wykonanie na innych maszynach	Nie jest jego rolą	Workery mogą działać niezależnie.

1. Prześledź lokalne powiadomienie

2. Zrozum zmianę wprowadzaną przez async

3. Prześledź zadanie w kolejce

4. Sprawdź lukę między zapisem a kolejką

5. Porównaj z rzeczywistą potrzebą

Powiązane pytania