EventEmitter khác hàng đợi công việc trong Node.js thế nào?

Question

IT Interview Practice · Accepted Answer

Để chọn EventEmitter hay job queue, hãy hỏi **công việc cần chạy ở đâu và điều gì xảy ra nếu process dừng**.

EventEmitter thông báo cho listener trong một process Node.js. Queue bền vững lưu công việc để worker xử lý sau. Cả hai giúp tách trách nhiệm, nhưng hành vi khi lỗi khác nhau.

## 1. Theo dõi một thông báo cục bộ

Giả sử một thành phần khởi tạo xong và muốn các thành phần khác trong cùng process phản ứng. EventEmitter phù hợp: đăng ký listener rồi phát sự kiện.

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

Node.js gọi listener đồng bộ theo thứ tự đăng ký. Bản thân sự kiện không được giữ cho listener đăng ký sau, và công việc chưa xong không sống qua crash của process. [Node.js Events](https://nodejs.org/api/events.html).

Cách này phù hợp khi thông báo mang tính cục bộ và có thể mất hoặc dựng lại. Nó không đủ khi nghiệp vụ yêu cầu công việc phải tồn tại sau khi bên gửi dừng.

## 2. Hiểu async listener thay đổi điều gì

Async listener có thể bắt đầu xử lý bất đồng bộ, nhưng emit không chờ promise mà listener trả về. Vì vậy, thứ tự gọi chưa chắc là thứ tự hoàn tất.

Code đồng bộ tính toán CPU nặng trong listener vẫn làm process chậm lại. Cần chủ động xử lý exception và promise bị reject; captureRejections có thể chuyển rejection sang xử lý lỗi, nhưng không lưu bền hay retry công việc.

Thêm async thay đổi cách listener thực hiện. Nó không biến sự kiện trong bộ nhớ thành queue bền vững.

## 3. Theo dõi một công việc qua queue

Bây giờ giả sử lưu đơn xong thì cuối cùng phải tạo được hóa đơn. Queue cung cấp nơi giữ yêu cầu trong lúc worker bận hoặc không hoạt động.

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

Producer gửi job; worker thực hiện một lần thử rồi ghi kết quả. Worker có thể triển khai và mở rộng riêng với API. Độ bền vẫn phụ thuộc nơi lưu và cấu hình queue.

Với queue có các worker cạnh tranh nhận việc thông thường, mỗi lần thử do một worker xử lý. Điều này khác phát sự kiện tới mọi listener của EventEmitter. Nếu nhiều subscriber độc lập đều cần nhận sự kiện, phải chọn hoặc cấu hình mô hình phân phối đáp ứng yêu cầu đó.

## 4. Kiểm tra khoảng trống giữa lưu dữ liệu và gửi job

Với EventEmitter, crash sau khi lưu đơn nhưng trước khi emit có thể làm mất yêu cầu tạo hóa đơn. Queue bền vững bảo vệ job sau khi đã nhận, nhưng không tự bảo vệ khoảng trống trước đó giữa commit database và gửi job.

Outbox khép khoảng trống bằng cách lưu đơn và yêu cầu công việc trong cùng transaction database. Publisher đọc outbox rồi gửi job sau.

Việc gửi có thể lặp nếu publisher mất xác nhận. Tạo hóa đơn cần khóa nghiệp vụ ổn định cùng ràng buộc duy nhất hoặc cách thực hiện idempotent khác. Thử lại không được tạo hóa đơn thứ hai. [Job có tính idempotent](https://docs.bullmq.io/patterns/idempotent-jobs).

## 5. So sánh theo nhu cầu thực tế

| Yêu cầu | EventEmitter | Job queue bền vững |
| --- | --- | --- |
| Báo cho thành phần trong một process | Trực tiếp, nhẹ | Thường thêm hạ tầng chưa cần thiết. |
| Giữ việc chờ sau khi bên gửi dừng | Không có bản ghi bền vững tích hợp | Có thể đáp ứng với lưu trữ và phục hồi phù hợp. |
| Retry và theo dõi việc tồn đọng | Ứng dụng phải tự xây | Là khả năng thường có của queue, cần cấu hình. |
| Chạy việc ở máy khác | Không phải vai trò của nó | Worker có thể chạy độc lập. |

Với ví dụ thông báo khởi tạo, tôi sẽ dùng EventEmitter. Với tạo hóa đơn phải phục hồi sau lỗi, tôi sẽ dùng queue bền vững và xử lý cả bước chuyển từ database sang queue lẫn các lần thử lặp.

Kiểm chứng bằng cách dừng process ở các mốc quan trọng: trước khi gửi, sau khi nhận và sau khi tạo tác dụng nghiệp vụ. Kết quả phải đúng với bảo đảm người dùng cần.

**Cách nhớ:** thông báo cục bộ → EventEmitter; công việc nền cần phục hồi → queue bền vững. Với tác dụng quan trọng, thiết kế thêm bước chuyển giao và idempotency.

Yêu cầu	EventEmitter	Job queue bền vững
Báo cho thành phần trong một process	Trực tiếp, nhẹ	Thường thêm hạ tầng chưa cần thiết.
Giữ việc chờ sau khi bên gửi dừng	Không có bản ghi bền vững tích hợp	Có thể đáp ứng với lưu trữ và phục hồi phù hợp.
Retry và theo dõi việc tồn đọng	Ứng dụng phải tự xây	Là khả năng thường có của queue, cần cấu hình.
Chạy việc ở máy khác	Không phải vai trò của nó	Worker có thể chạy độc lập.

1. Theo dõi một thông báo cục bộ

2. Hiểu async listener thay đổi điều gì

3. Theo dõi một công việc qua queue

4. Kiểm tra khoảng trống giữa lưu dữ liệu và gửi job

5. So sánh theo nhu cầu thực tế

Câu hỏi liên quan