20

私の無知を許してください.Django / Pythonのバックグラウンドから来た私は、ウェブインターフェースができるだけ速く更新されている間、バックグラウンドで遅いプロセスを介して動作するCeleryキューを持つことの大きな利点を見ることができます.

しかし、Node が非同期で動作する場合、キュー システムのユース ケースは大幅に減少しますか?

例えば：

1 - ユーザーがサイトに何かを投稿します。2 - サイトが応答し、管理者にメールを送信します。

Django では、管理メールをタスクに送信して後で実行し、リクエストに応答します。Celery はバックグラウンドでメールを送信します。

Node では、メーラーを呼び出してから、リクエストに応答します。次に、メーラーは DONE かどうかを伝えるコールバックを送信します。この時点で、ユーザーはすでに応答を表示しています。

では、なぜ Node.js でキューを使用するのでしょうか? 物事がこれより複雑になるときを推測しています - トランザクションメールのような些細なことについては、それは必要ないようです..

それとも、私はそれがどのように機能するかを誤解しています!?

4

2 に答える 2

7

そうです、継続はノードで非常に優れており、単一のノード プロセスですべてを実行している場合、キューはすぐには必要ありません。ただし、ノードはシングル スレッドであるため、そのメールの送信またはそのタスクの処理でビジー状態の間 (CPU を集中的に使用するタスクの場合)、ノードは新しい着信要求を処理できません。

そのため、タスクが CPU の処理に時間がかかる場合でも、外部キューと別のプロセスを使用してそれらのタスク/メッセージを処理する価値があるかもしれません。たとえば、タスクが io を集中的に使用し、他のサーバーからの応答を待っているために時間がかかる場合は、ノードが io を適切に処理するため、再度必要になることは少なくなります。

CPU を集中的に使用するタスクがあり、キューをデプロイしたくない場合は、より多くのノード プロセスとマシン インスタンスを作成し、それらの間で負荷を分散して、これらのタスクをすべて処理できるようにすることができます。このアプローチの欠点は、Web サイトとバックグラウンド処理を別々にスケーリングできないことです。(例: Web リクエストを処理する 5 つのインスタンスと 2 つのワーカー インスタンス)

于 2013-02-21T01:47:18.550 に答える
4

いいえ、ノードの世界であっても、キューの使用例は常にあります。さまざまな程度の成功を収めるために何人かの人々が使用している基本的なアプローチは、Redis でサポートされたキューを使用してメッセージまたはタスクを保存することです。1 つの Node プロセスでアイテムをキューに追加し、別の Node インスタンスでキューからアイテムを処理することができます。さらに、キュー モジュールのノード モジュール リストを見てください。かなりの量の実装が表示されます。

于 2013-02-20T20:08:26.127 に答える