Чем EventEmitter отличается от очереди заданий в Node.js?

Question

IT Interview Practice · Accepted Answer

Выбирайте между EventEmitter и очередью заданий, выяснив, **где должна выполняться работа и что произойдёт при остановке процесса**.

EventEmitter уведомляет слушателей внутри одного процесса Node.js. Долговечная очередь сохраняет работу для последующей обработки worker. Оба подхода разделяют обязанности, но по-разному ведут себя при сбоях.

## 1. Проследите локальное уведомление

Допустим, компонент закончил инициализацию и хочет вызвать реакцию других компонентов того же процесса. EventEmitter естественно подходит: зарегистрируйте слушателей, затем отправьте событие.

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

Node.js синхронно вызывает зарегистрированных слушателей в порядке регистрации. Само событие не сохраняется для тех, кто зарегистрируется позже, а незавершённая работа не переживает падение процесса. [События Node.js](https://nodejs.org/api/events.html).

Это работает для локального уведомления, которое можно потерять или восстановить. Этого недостаточно, когда бизнес ожидает, что работа переживёт отправителя.

## 2. Поймите, что меняет async-слушатель

Async-слушатель может начать асинхронную работу, но emit не ждёт возвращённый promise. Поэтому порядок вызова не обязательно совпадает с порядком завершения.

Синхронный CPU-тяжёлый код внутри слушателя всё равно задерживает процесс. Явно обрабатывайте выброшенные ошибки и отклонённые promise; captureRejections направляет отклонения в обработку ошибок, но не сохраняет и не повторяет задачу.

Добавление async меняет способ выполнения слушателя. Оно не превращает событие в памяти в долговечную очередь.

## 3. Проследите задание в очереди

Теперь предположим, что сохранённый заказ должен в итоге получить счёт. Очередь предоставляет место для инструкции, пока worker заняты или недоступны.

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

Производитель отправляет задание; worker выполняет попытку и фиксирует результат. Worker можно развёртывать и масштабировать отдельно от API. Долговечность всё равно зависит от хранилища и конфигурации очереди.

В обычной очереди с конкурирующими worker каждую попытку обрабатывает один worker. Это отличается от отправки события каждому слушателю EventEmitter. Если событие нужно каждому из нескольких независимых подписчиков, выберите или настройте соответствующую модель доставки.

## 4. Проверьте разрыв между сохранением и постановкой в очередь

С EventEmitter сбой после сохранения заказа, но до emit, может потерять инструкцию выставить счёт. Долговечная очередь защищает задание после принятия, но автоматически не закрывает предыдущий разрыв между commit базы и отправкой.

Outbox закрывает разрыв, сохраняя заказ и инструкцию в одной транзакции базы. Издатель читает outbox и отправляет задание позднее.

Доставка может повториться при потере подтверждения издателем. Дайте созданию счёта стабильный бизнес-ключ и ограничение уникальности или другую идемпотентную реализацию. Повтор попытки не должен создавать второй счёт. [Идемпотентные задания](https://docs.bullmq.io/patterns/idempotent-jobs).

## 5. Сравните варианты с реальной потребностью

| Требование | EventEmitter | Долговечная очередь заданий |
| --- | --- | --- |
| Уведомлять компоненты одного процесса | Просто и легко | Обычно добавляет лишнюю инфраструктуру. |
| Сохранять работу после остановки отправителя | Нет встроенной долговечной записи | Возможно с подходящим хранилищем и восстановлением. |
| Повторять и исследовать накопившуюся работу | Приложение реализует самостоятельно | Обычные возможности очередей, требующие настройки. |
| Выполнять работу на других машинах | Не его назначение | Worker могут работать независимо. |

Для примера инициализации я бы выбрал EventEmitter. Для выставления счетов с восстановлением после сбоя — долговечную очередь, решив вопросы передачи из базы и повторных попыток.

Проверяйте остановкой процесса на важных границах: перед отправкой, после принятия и после бизнес-эффекта. Результат должен соответствовать ожидаемой пользователем гарантии.

**Запомните:** локальное уведомление → EventEmitter; восстанавливаемая фоновая работа → долговечная очередь. Для критических эффектов также проектируйте передачу и идемпотентность.

Требование	EventEmitter	Долговечная очередь заданий
Уведомлять компоненты одного процесса	Просто и легко	Обычно добавляет лишнюю инфраструктуру.
Сохранять работу после остановки отправителя	Нет встроенной долговечной записи	Возможно с подходящим хранилищем и восстановлением.
Повторять и исследовать накопившуюся работу	Приложение реализует самостоятельно	Обычные возможности очередей, требующие настройки.
Выполнять работу на других машинах	Не его назначение	Worker могут работать независимо.

1. Проследите локальное уведомление

2. Поймите, что меняет async-слушатель

3. Проследите задание в очереди

4. Проверьте разрыв между сохранением и постановкой в очередь

5. Сравните варианты с реальной потребностью

Похожие вопросы