Apakah beza EventEmitter dengan baris gilir job dalam Node.js?

Question

IT Interview Practice · Accepted Answer

Pilih EventEmitter atau baris gilir tugas dengan bertanya **di mana kerja mesti berjalan dan apa berlaku jika proses berhenti**.

EventEmitter memberitahu pendengar dalam satu proses Node.js. Baris gilir tahan lama menyimpan kerja untuk diproses pekerja kemudian. Kedua-duanya memisahkan tanggungjawab tetapi kelakuan kegagalannya berbeza.

## 1. Ikuti pemberitahuan setempat

Andaikan komponen selesai dimulakan dan mahu komponen lain dalam proses sama bertindak. EventEmitter sesuai: daftar pendengar, kemudian keluarkan peristiwa.

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

Node.js memanggil pendengar secara segerak mengikut turutan pendaftaran. Peristiwa tidak disimpan untuk pendengar yang mendaftar kemudian, dan kerja belum selesai tidak bertahan selepas proses rosak. [Node.js Events](https://nodejs.org/api/events.html).

Ini sesuai apabila pemberitahuan setempat boleh hilang atau dibina semula. Ia tidak mencukupi jika kerja mesti terus wujud selepas penghantar berhenti.

## 2. Fahami perubahan oleh pendengar async

Pendengar async boleh memulakan kerja tak segerak, tetapi emit tidak menunggu promise yang dipulangkan. Turutan panggilan bukan semestinya turutan penyelesaian.

Kod segerak yang berat pada CPU dalam pendengar masih melambatkan proses. Kendalikan ralat dan penolakan promise secara sengaja; captureRejections boleh mengarahkannya ke pengendalian ralat, tetapi tidak menyimpan atau mencuba semula tugas.

Async mengubah cara pendengar bekerja. Ia tidak menjadikan peristiwa dalam memori sebagai baris gilir tahan lama.

## 3. Ikuti tugas dalam baris gilir

Kini andaikan penyimpanan pesanan mesti akhirnya menghasilkan invois. Baris gilir menyimpan arahan apabila pekerja tiada atau sibuk.

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

Pengeluar menyerahkan tugas; pekerja menjalankan percubaan dan merekod hasil. Pekerja boleh ditempatkan dan diskalakan berasingan daripada API. Ketahanan masih bergantung pada storan dan tetapan baris gilir.

Dalam baris gilir pekerja bersaing yang biasa, seorang pekerja mengendalikan setiap percubaan. Ini berbeza daripada penyiaran kepada semua pendengar EventEmitter. Jika beberapa pelanggan bebas masing-masing memerlukan peristiwa, pilih atau tetapkan model penghantaran yang menyokongnya.

## 4. Semak jurang antara simpan dan hantar

Dengan EventEmitter, kerosakan selepas pesanan disimpan tetapi sebelum peristiwa dikeluarkan boleh menghilangkan arahan invois. Baris gilir tahan lama melindungi tugas selepas menerima, tetapi tidak melindungi jurang sebelumnya antara komit pangkalan data dan penyerahan secara automatik.

Outbox menutup jurang dengan menyimpan pesanan dan arahan dalam transaksi sama. Penerbit membaca outbox dan menghantar tugas kemudian.

Penghantaran boleh berulang jika penerbit kehilangan pengesahan. Berikan penciptaan invois kunci perniagaan stabil dan kekangan unik atau pelaksanaan idempoten lain. Percubaan berulang tidak boleh mencipta invois kedua. [Tugas idempoten](https://docs.bullmq.io/patterns/idempotent-jobs).

## 5. Bandingkan dengan keperluan sebenar

| Keperluan | EventEmitter | Baris gilir tahan lama |
| --- | --- | --- |
| Memberitahu komponen dalam satu proses | Terus dan ringan | Lazimnya menambah infrastruktur tidak perlu. |
| Menyimpan kerja selepas penghantar berhenti | Tiada rekod tahan lama terbina dalam | Boleh dengan storan dan pemulihan sesuai. |
| Cuba semula dan lihat tunggakan | Aplikasi perlu membinanya | Keupayaan biasa baris gilir, dengan tetapan. |
| Menjalankan kerja di mesin lain | Bukan peranannya | Pekerja boleh berjalan bebas. |

Untuk permulaan komponen, saya memilih EventEmitter. Untuk invois yang mesti pulih daripada kegagalan, saya memilih baris gilir tahan lama dengan penyerahan pangkalan data dan percubaan pendua dikendalikan.

Uji dengan menghentikan proses pada sempadan penting: sebelum penyerahan, selepas penerimaan dan selepas kesan perniagaan. Hasil mesti sepadan dengan jaminan yang dijangka pengguna.

**Ingat:** pemberitahuan setempat → EventEmitter; kerja latar yang boleh dipulihkan → baris gilir tahan lama. Untuk kesan kritikal, reka juga penyerahan dan idempotensi.

Keperluan	EventEmitter	Baris gilir tahan lama
Memberitahu komponen dalam satu proses	Terus dan ringan	Lazimnya menambah infrastruktur tidak perlu.
Menyimpan kerja selepas penghantar berhenti	Tiada rekod tahan lama terbina dalam	Boleh dengan storan dan pemulihan sesuai.
Cuba semula dan lihat tunggakan	Aplikasi perlu membinanya	Keupayaan biasa baris gilir, dengan tetapan.
Menjalankan kerja di mesin lain	Bukan peranannya	Pekerja boleh berjalan bebas.

1. Ikuti pemberitahuan setempat

2. Fahami perubahan oleh pendengar async

3. Ikuti tugas dalam baris gilir

4. Semak jurang antara simpan dan hantar

5. Bandingkan dengan keperluan sebenar

Soalan berkaitan