Node.jsのバックグラウンドプロセス
NodeJSアプリケーションでバックグラウンドプロセスを処理する良い方法は何ですか？
シナリオ：ユーザーがアプリに何かを投稿した後、データを処理したり、外部リソースから追加のデータを要求したりします。これらはすべて非常に時間がかかるため、req/resループ。理想は、ジョブをすばやくダンプできるジョブのキューを用意することであり、デーモンまたはタスクランナーは常に最も古いジョブを取得して処理します。
RoRでは、Delayed Jobのようなものでそれをしたでしょう。このAPIに相当するNodeとは何ですか？
サーバーと同じプロセスで実行される軽量なものが必要な場合は、 Bull を強くお勧めします。キューをきめ細かく制御できるシンプルなAPIがあります。
スタンドアロンワーカープロセスとして実行されるものを探している場合は、おそらく Kue を調べてください。 RESTful APIサーバーとして実行でき、いくつかのフロントエンドアプリも記述されています。
RubyのResqueに慣れている場合は、 Node-resque というノード実装があります
Bull、Kue、およびNode-resqueはすべて、 Redis によってサポートされています。これはNode.jsワーカーキューのいたるところにあります。 3つすべてがRoRのDelayedJobの機能を実行できます。これは、必要な特定の機能とAPIの設定の問題です。
バックグラウンドジョブはWebサービスの作業に直接関連していないため、同じプロセスにあるべきではありません。スケールアップすると、バックグラウンドジョブのメモリ使用量がWebサービスのパフォーマンスに影響します。ただし、必要に応じて同じコードリポジトリに配置することができます。
2つのプロセス間でのメッセージングの適切な選択の1つは、 redis です。これは、時々メッセージをドロップしても問題ない場合です。 「メッセージを残しません」が必要な場合は、 Rabbit のようなより強力なブローカーが必要です。 Webサービスプロセスを公開し、バックグラウンドジョブプロセスをサブスクライブできます。
2つのプロセスをホストする必要はありません。別々のVM、Dockerコンテナなど、どのようなものでも使用できます。これにより、問題なくスケールアウトできます。
ジョブのスケジュールに Redis を使用することをお勧めします。さまざまなデータ構造があり、ユースケースにより適したものをいつでも選択できます。
あなたはRoRとDJに言及したので、sidekiqに精通していると思います。必要に応じて node-sidekiq をジョブスケジューリングに使用できますが、その最適なimoは、nodejsをRoRと統合することが主な目的であるためです。
ワーカーのデーモン化には、 PM2 を使用することをお勧めします。広く使用されており、積極的にメンテナンスされています。これは多くの問題（展開、監視、クラスタリングなど）を解決するので、それが過剰にならないようにしてください。
bee-queue ＆ bull を試し、最後にbullを選択しました。私は最初、蜂キューb/cを選択しました。これは非常に単純で、その例は理解しやすいですが、ブルの例は少し複雑です。蜂のwiki Bee Queue's Origin も私に共鳴します。しかし、ミツバチの問題は<1>問題解決時間が非常に遅いことです。最新の更新は10か月前でした。 <2>ジョブを一時停止/キャンセルする簡単な方法が見つかりません。
一方、Bullは頻繁にコードを更新し、問題に対応しています。 Node.jsジョブキューの評価 ブルの弱点は「問題の解決に時間がかかる」と言いましたが、私の経験は逆です！
しかし、とにかくAPIは似ているため、あるAPIから別のAPIに簡単に切り替えることができます。