Node.js içinde EventEmitter ile iş kuyruğu arasındaki fark nedir?

Question

IT Interview Practice · Accepted Answer

EventEmitter ile iş kuyruğu arasında seçim yaparken **işin nerede çalışması gerektiğini ve süreç durursa ne olacağını** sorun.

EventEmitter tek bir Node.js sürecindeki dinleyicileri bilgilendirir. Kalıcı kuyruk, worker'ların daha sonra işlemesi için işi saklar. İkisi de sorumlulukları ayırır ancak hata davranışları farklıdır.

## 1. Yerel bir bildirimi izleyin

Bir bileşenin başlangıç hazırlığını tamamladığını ve aynı süreçteki diğer bileşenlerin tepki vermesini istediğini varsayalım. EventEmitter doğal bir seçimdir: dinleyicileri kaydedin, sonra olayı yayınlayın.

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

Node.js kayıtlı dinleyicileri kayıt sırasıyla eşzamanlı çağırır. Olay, sonradan kaydolan dinleyiciler için saklanmaz ve bitmemiş iş süreç çökmesinden sonra yaşamaz. [Node.js Events](https://nodejs.org/api/events.html).

Bildirim yerelse ve kaybolabilir veya yeniden üretilebilirse bu uygundur. İşin göndericiden sonra da var olması bekleniyorsa yetersiz kalır.

## 2. Async dinleyicinin neyi değiştirdiğini anlayın

Async dinleyici asenkron iş başlatabilir; ancak emit, dönen promise'i beklemez. Dolayısıyla çağrı sırası mutlaka tamamlanma sırası değildir.

Dinleyicide CPU yoğun eşzamanlı kod yine süreci geciktirir. Fırlatılan hataları ve reddedilen promise'leri bilinçli yönetin; captureRejections, reddetmeleri hata yönetimine yönlendirebilir ancak görevi kalıcı saklamaz veya yeniden denemez.

Async eklemek dinleyicinin işi nasıl yaptığını değiştirir. Bellekteki olayı kalıcı kuyruğa dönüştürmez.

## 3. Kuyruktaki görevi izleyin

Şimdi bir siparişi kaydetmenin sonunda mutlaka fatura üretmesi gerektiğini varsayalım. Kuyruk, worker'lar kullanılamaz veya meşgulken talimatı tutacak yer sağlar.

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

Üretici işi gönderir; worker bir denemeyi işler ve sonucu kaydeder. Worker'lar API'den ayrı dağıtılıp ölçeklenebilir. Kalıcılık yine kuyruğun depolama ve yapılandırmasına bağlıdır.

Tipik bir yarışan-worker kuyruğunda her denemeyi tek worker işler. Bu, olayı her EventEmitter dinleyicisine yayınlamaktan farklıdır. Birden fazla bağımsız abonenin her birinin olaya ihtiyacı varsa bu gereksinimi destekleyen teslim modelini seçin veya yapılandırın.

## 4. Kaydetme ile kuyruğa gönderme arasındaki boşluğu kontrol edin

EventEmitter kullanırken sipariş kaydedildikten sonra ancak olay yayınlanmadan önce çökme, fatura talimatını kaybettirebilir. Kalıcı kuyruk işi kabul ettikten sonra korur, ancak veritabanı commit'i ile gönderim arasındaki önceki boşluğu otomatik korumaz.

Outbox, siparişle talimatını aynı veritabanı transaction'ında saklayarak boşluğu kapatır. Yayıncı outbox'ı okur ve işi daha sonra gönderir.

Yayıncı onayı kaybederse teslim tekrarlanabilir. Fatura oluşturmaya sabit iş anahtarı ve benzersizlik kısıtı veya başka idempotent uygulama verin. Bir denemeyi tekrarlamak ikinci faturayı oluşturmamalıdır. [Idempotent işler](https://docs.bullmq.io/patterns/idempotent-jobs).

## 5. Seçenekleri gerçek ihtiyaca göre karşılaştırın

| Gereksinim | EventEmitter | Kalıcı iş kuyruğu |
| --- | --- | --- |
| Tek süreçteki bileşenleri bilgilendirmek | Doğrudan ve hafif | Genellikle gereksiz altyapı ekler. |
| Gönderici durduktan sonra bekleyen işi tutmak | Yerleşik kalıcı kayıt yok | Uygun depolama ve kurtarmayla mümkün. |
| Yeniden denemek ve birikmiş işi incelemek | Uygulama bunu kurmalıdır | Yapılandırma gerektiren yaygın kuyruk yetenekleri. |
| İşi başka makinelerde çalıştırmak | Görevi bu değildir | Worker'lar bağımsız çalışabilir. |

Başlangıç hazırlığı örneğinde EventEmitter kullanırdım. Hatalardan kurtulması gereken fatura üretiminde kalıcı kuyruk kullanır, veritabanından devri ve tekrarlanan denemeleri ele alırdım.

Önemli sınırlarda süreci durdurarak test edin: gönderimden önce, kabulden sonra ve iş etkisinden sonra. Sonuç kullanıcının beklediği garantiyle eşleşmelidir.

**Unutmayın:** yerel bildirim → EventEmitter; kurtarılabilir arka plan işi → kalıcı kuyruk. Kritik etkiler için devri ve idempotency'yi de tasarlayın.

Gereksinim	EventEmitter	Kalıcı iş kuyruğu
Tek süreçteki bileşenleri bilgilendirmek	Doğrudan ve hafif	Genellikle gereksiz altyapı ekler.
Gönderici durduktan sonra bekleyen işi tutmak	Yerleşik kalıcı kayıt yok	Uygun depolama ve kurtarmayla mümkün.
Yeniden denemek ve birikmiş işi incelemek	Uygulama bunu kurmalıdır	Yapılandırma gerektiren yaygın kuyruk yetenekleri.
İşi başka makinelerde çalıştırmak	Görevi bu değildir	Worker'lar bağımsız çalışabilir.

1. Yerel bir bildirimi izleyin

2. Async dinleyicinin neyi değiştirdiğini anlayın

3. Kuyruktaki görevi izleyin

4. Kaydetme ile kuyruğa gönderme arasındaki boşluğu kontrol edin

5. Seçenekleri gerçek ihtiyaca göre karşılaştırın

İlgili sorular