11

Node.jsを使用してjavascriptで書かれた、データサーバーに面したメインアプリケーションの外部でタスクを処理する責任があるプロジェクトに作品を書いています。将来スケジュールされたタスクを処理する必要があり、「現在」のタスクを処理する可能性があります。「今すぐ」というのは、ワーカーが次に利用可能になったときにそのタスクで動作することを意味するだけなので、そのビットは問題にならない可能性があります。ワーカーはすべて外部リソースと対話します。たとえば、電子メールの送信がジョブの例です。私たちは小さなショップであり、大量のリソースを持っていないので、プロセスのこの時点で言語の混合を開始したくないのですが、Node.js がこれを非常に簡単に実行できることはすでにわかっています。それが私たちのことです」

とは言っても、OpenAMQやRabbitMQなどの AMQP ベースのサーバーを、 KueやBeanstalkdなどのノード クライアントで使用する必要があるかどうかはわかりません。それで、ここに行きます：

beanstalkd や Kue を使用した redis などで AMQP ベースのサーバーを使用する説得力のある理由はありますか? はいの場合、私が設計したアーキテクチャに最適な AMPQ ベースのサーバーはどれですか? 「いいえ」の場合、どの nosql ソリューション (beanstalkd、redis/Kue) をセットアップするのが最も簡単で、デプロイするのが最も速いですか?

4

1 に答える 1

16

FWIW、私はまだ私の答えを受け入れていません。私が決定したこととその理由を説明します。私が決めたものよりも良いと思われる回答が得られない場合は、後で自分の回答を受け入れます.

クエに決めました。非同期で実行される複数のワーカーをサポートし、クラスターを使用してマルチコア システムを利用できます。セキュリティを提供するために簡単に拡張できます。これは Redis でサポートされており、Redis はまさにこの目的のために使用されているため、証明されていないソフトウェアでジョブ プロセス サーバーをサポートしているわけではないことはわかっています (他のソフトウェアが証明されていないと言っているわけではありません)。

私が Kue を選んだ最も説得力のある理由は、クライアント アプリケーション (最初のクライアントは Web ベースのアプリケーションになる予定ですが、スマートフォン アプリも作成する予定です) が簡単にジョブを追加できるように、JSON API を提供することです。ノードインスタンスに面するメインアプリケーションを介して、これを書いているときにチームの他のメンバーの邪魔にならないようにすることができます。ルートも何も必要ありません。すべて提供されているので、これをサポートするために何も書く必要はありません。これには別の利点があります.l/pセキュリティを提供する拡張機能により、許可されたクライアントのみがジョブを追加できるため、redisサーバーをクライアントアプリケーションに直接公開する必要はありません. また、組み込みの Web コンソールがあり、API により、クライアントは特定のユーザーに関連付けられたジョブのリストを非常に簡単に取得できます。

もう 1 つの説得力のある理由は、redis と Kue の取得に関連する急な学習曲線がないことです。以前に redis をセットアップしたことがあり、Kue はシンプルで効果的です。

はい、私は怠惰な開発者ですが、私は怠け者の良い種類の開発者です。

アップデート：

私はそれを機能させ、仕事をしています。スループットは驚くべきものです。タスク マーシャリング ロジックを独自のノード インスタンスに分割しました。基本的には、リポジトリを新しいマシンにデプロイし、node task-server.js を実行してワーカーをスケールアウトするだけです。いくつかのことを実装したため、Kue への求人検索の呼び出しを追加する必要があるかもしれませんが、それは簡単です。

于 2012-05-03T00:19:56.677 に答える