Node.js の EventEmitter とジョブキューはどう違う？

Question

IT Interview Practice · Accepted Answer

EventEmitterとジョブキューは、**処理をどこで動かし、プロセスが止まったらどうするか**で選びます。

EventEmitterは1つのNode.jsプロセス内のリスナーに通知します。永続キューは、ワーカーが後で処理する仕事を保存します。どちらも責任を分離しますが、障害時の動作が異なります。

## 1. ローカル通知の流れを見る

あるコンポーネントが初期化を終え、同じプロセスの他のコンポーネントに反応してほしいとします。EventEmitterが自然な選択です。リスナーを登録してイベントを発行します。

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

Node.jsは登録順にリスナーを同期的に呼びます。イベント自体は後から登録するリスナーのために保存されず、未完了の仕事はプロセスの異常終了を超えて残りません。[Node.js Events](https://nodejs.org/api/events.html)。

通知がローカルで、失われてもよいか再構築できるなら適しています。送り手が止まっても仕事が残るという業務要件には不十分です。

## 2. asyncリスナーで変わる点を理解する

asyncリスナーは非同期処理を開始できますが、emitは返されたPromiseを待ちません。そのため、呼び出し順と完了順は必ずしも一致しません。

リスナー内のCPUを使う同期コードは、引き続きプロセスを遅らせます。例外とPromiseの拒否は明示的に扱います。captureRejectionsは拒否をエラー処理に回せますが、仕事を保存したり再試行したりはしません。

asyncの追加はリスナーの処理方法を変えます。メモリ上のイベントを永続キューに変えるわけではありません。

## 3. キューに入れた仕事の流れを見る

今度は、注文を保存したら最終的に請求書を生成する必要があるとします。キューは、ワーカーが不在または多忙な間、指示を保持する場所になります。

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

プロデューサーがジョブを送り、ワーカーが1回の試行を処理して結果を記録します。ワーカーはAPIとは別に配置、拡張できます。ただし、永続性はキューの保存先と設定に依存します。

一般的な競合ワーカー型キューでは、各試行を1つのワーカーが担当します。EventEmitterの全リスナーに通知する動作とは異なります。独立した複数の購読者がそれぞれイベントを必要とするなら、その要件に合う配送モデルを選ぶか設定します。

## 4. 保存からキュー投入までの隙間を確認する

EventEmitterでは、注文保存後、イベント発行前に止まると、請求書の指示を失うことがあります。永続キューは受け付けた後のジョブを守りますが、それ以前のデータベースコミットと送信の間を自動では守りません。

outboxは注文と指示を同じデータベーストランザクションに保存して、その隙間を閉じます。パブリッシャーがoutboxを読み、後からジョブを送信します。

パブリッシャーが確認応答を失うと、配送は重複することがあります。請求書作成には安定した業務キーと一意制約、または別の冪等な実装を用意します。再試行で2枚目の請求書を作ってはいけません。[冪等なジョブ](https://docs.bullmq.io/patterns/idempotent-jobs)。

## 5. 実際の要件で比較する

| 要件 | EventEmitter | 永続ジョブキュー |
| --- | --- | --- |
| 同一プロセスのコンポーネントへ通知 | 直接的で軽量 | 通常は不要な基盤が増える。 |
| 送り手の停止後も未処理の仕事を保持 | 永続記録の組み込み機能はない | 適切な保存と復旧で可能。 |
| 再試行と滞留の確認 | アプリケーション側で実装する | 一般的なキューの機能だが設定が必要。 |
| 別のマシンで実行 | 役割の範囲外 | ワーカーを独立して動かせる。 |

初期化の例ならEventEmitterを使います。障害から復旧すべき請求書生成なら、永続キューを使い、データベースからの受け渡しと重複試行にも対処します。

送信前、受付後、業務効果の発生後という重要な境界でプロセスを止めて試します。結果がユーザーの期待する保証と一致する必要があります。

**要点：**ローカル通知はEventEmitter、復旧可能なバックグラウンド処理は永続キュー。重要な効果には、仕事の受け渡しと冪等性も設計します。

要件	EventEmitter	永続ジョブキュー
同一プロセスのコンポーネントへ通知	直接的で軽量	通常は不要な基盤が増える。
送り手の停止後も未処理の仕事を保持	永続記録の組み込み機能はない	適切な保存と復旧で可能。
再試行と滞留の確認	アプリケーション側で実装する	一般的なキューの機能だが設定が必要。
別のマシンで実行	役割の範囲外	ワーカーを独立して動かせる。

1. ローカル通知の流れを見る

2. asyncリスナーで変わる点を理解する

3. キューに入れた仕事の流れを見る

4. 保存からキュー投入までの隙間を確認する

5. 実際の要件で比較する

関連する質問