nodejsのワーカーキュー？
ノードのクラスターAPIとマングースを使用してノードのワーカーキューを作成し始めています。
すでにこれを行っているが、redisとフォークを使用しているライブラリがたくさんあることに気づきました。クラスターAPIを使用するのではなくフォークする正当な理由はありますか？
editそして今私もこれを見つけます： https://github.com/xk/node-threads-a-gogo -オプションが多すぎます！
私はすでにmongoを使用しているので、ミックスにredisを追加したくありません。また、私の要件は非常に緩いので、永続性が欲しいのですが、最初のバージョンではそれなしで済ますことができます。
質問のパート2：今日最も安定した/使用されているnodejsワーカーキューライブラリは何ですか？
試しましたか https://github.com/rvagg/node-worker-farm ？非常に軽量で、別のサーバーを必要としません。
私は個人的にクラスターマスターに偏っています。
https://github.com/isaacs/cluster-master
私がクラスターマスターが好きな理由は、プロセスをフォークするためのロジックを追加する以外にほとんど何もせず、実行中のプロセスの数を管理する機能と、起動するための少しのロギング/リカバリを提供するためです！過度に肥大化したプロセス管理ライブラリは不安定になる傾向があり、場合によっては速度が低下することさえあります。
このライブラリは、次のことが当てはまる場合に役立ちます。
- モジュールはほとんど非同期です
- トリガーとなるさまざまな種類のイベントが大量にあるわけではありません
- 発生するイベントにはやるべき作業が少しありますが、同様のイベントがたくさん発生します（Webサーバーなど）
上記のリストの理由は、反対の理由で、threads-a-gogoがあなたにとって良いかもしれない理由です。コード内にイベントループ内で行うべき作業がたくさんある場所がいくつかある場合、この作業専用の「スレッド」を起動するthreads-a-gogoのようなものは、決定していないので素晴らしいです。事前に何人のワーカーをスポーンするかではなく、必要なときに作業を行うためにスポーンします。注：これは、多くのプロセスが生成される可能性がある場合にも悪い可能性があります。起動し始めるプロセスが多すぎると、実際には問題が発生する可能性がありますが、私は逸脱します。
要約すると、モジュールがすでに大部分が非同期である場合、本当に必要なのはワーカープールです。プロセスがイベントをリッスンしていないときのダウンタイムを最小限に抑え、使用できるプロセッサの量を最大化するため。非常にビジーな同期呼び出しがない限り、単一ノードのイベントループでは、プロセッサの単一コアを利用する場合でも問題が発生します。このような状況では、クラスターマスターを使用するのが最善です。私がお勧めするのは、少しベンチマークを実行し、「最悪のシナリオ」でプログラムが使用できる単一コアの量を確認することです。これが1つのコアの33％であるとしましょう。クアッドコアマシンを使用している場合は、クラスターマスターに12人のワーカーを起動するように指示します。
これがお役に立てば幸いです。