リアルタイムのライブWebアプリ開発を行っています。
ブラウザのユーザーは、node.jsサーバーを介して相互に通信できる必要があります。ユーザーの1人がメッセージを書き込み、他のすべてのユーザーがそれを受け取ります。
RabbitMQがどのように機能するか、私にはよくわかりません。しかし、手早く読むと、それはメッセージの公開/購読を処理するようです。
ユーザー(ブラウザー内)が何かを公開し、サブスクライバー(他のブラウザー内)がそのメッセージを受け取ります。それはSocket.ioがwebsocketで何をしているのではないですか?
ここに私の質問があります:
Socket.ioでは不十分なWebアプリにRabbitMQが必要なシナリオはありますか?ブラウザのユーザーは、node.jsサーバーを介して相互に通信できる必要があります。ユーザーの1人がメッセージを書き込み、他のすべてのユーザーがそれを受け取ります。
これらの単純な要件しかない場合は、socket.ioだけで十分です。ジョブ(重い)をオフラインで制御された方法で処理する場合にのみ、メッセージ queue が必要です。
http://en.wikipedia.org/wiki/Message_queue :
メッセージキューは非同期通信プロトコルを提供します。つまり、メッセージの送信者と受信者が同時にメッセージキューと対話する必要はありません。
この文はシンクする必要があります。プロデューサ(1つのプロセス)はジョブをキューに入れ、コンシューマはジョブをキューから取得することによって消費します。ほとんどの場合、コンシューマは複数のジョブを同時に消費する複数のプロセスです。消費者は、彼らが消費している仕事を互いに区別することができません。
これにより、キューは先入れ先出し(FIFO)データ構造になります。
それがキューの重要な特性だと思います。 First-In-First-Outプロパティ。ただし、beanstalkdなどの高度なメッセージキューを使用すると、ジョブに優先順位を付けることができます。
これが意味をなさないことを願っています
リアルタイムのライブWebアプリ開発を行っています。
より良い答えを提供できるように、もう少し詳しく説明してもらえますか?
RabbitMQがどのように機能するか、私にはよくわかりません。しかし、手早く読むと、それはメッセージの公開/購読を処理するようです。
以下のメッセージキューに関する引用を参照してください。しばらく沈めてみましょう。 メッセージキュー に関するWIKIを読むこともできます。
ユーザー(ブラウザー内)が何かを公開し、サブスクライバー(他のブラウザー内)がそのメッセージを受け取ります。それはSocket.ioがwebsocketで何をしているのではないですか?
Socket.ioは多くの異なるトランスポート(WebSocketも含む)をサポートしますが、WebSocketはほとんどのブラウザーでサポートされていないため、サポートする必要があります。しかし、例えばGoogle ChromeはすでにWebSocketをサポートしています。WebSocketは未来のトランスポートであると信じています(しかし、まだではありません!)。 Socket.ioを見るとブラウザーサポートページ では、Socket.ioがすべての主要なブラウザー(一部は古くても)をサポートしていることがわかります。
それらのそれぞれの利点/欠点は何ですか?
あなたはリンゴをオレンジと比較しているので、それを比較するのはちょっと奇妙です。
http://www.rabbitmq.com/tutorials/tutorial-one-python.html :
RabbitMQはメッセージブローカーです。基本的な考え方は非常に単純です。メッセージを受け入れて転送します。あなたはそれを私書箱と考えることができます:郵便ポストに郵便物を送るとき、あなたはポストマン氏が最終的にあなたの受取人に郵便物を配達するであろうことをかなり確信しています。この比喩を使用すると、RabbitMQは私書箱、私書箱、郵便配達になります。
Socket.IOは、リアルタイムアプリをすべてのブラウザーおよびモバイルデバイスで使用できるようにすることを目的としており、さまざまなトランスポートメカニズムの違いをぼかします。
Socket.ioはRabbitMQを置き換えることができますか?
それらは2つのまったく異なるものであるため、できません。リンゴとオレンジを比較しています。私が引用したサイトの両方の説明を理解するようにしてください。
RabbitMQは、ネットワークトポロジを柔軟に作成する方法です。それは成熟していて、サポートされており、ファイナンスの分野から来ています(ファイナンスでは、彼らは長い間メッセージングを行ってきました)。 RabbitMQのサーバー側を使用し、他のプロトコルを使用して「ゲートウェイ」経由でRabbitMQに接続します。
背後では、RabbitMQはErlangと呼ばれる非常に簡潔な関数型言語で記述されています。それ自体は大した問題ではありませんが、何をしているのかがわかっていて、少ないコード行でそれを言うことができれば、最終的にはより信頼性が高く、テストしやすくなるという競合があります。
btw:Erlangは、FacebookやTwitterの舞台裏で使用されています。
今、RabbitMQは単なるネットワークソケットタイプのものではありません...それは「保証された配信」に基づいています。この機能は企業の状況にとって重要です。 RabbitMQは、代わりにスケーリングに使用できます...実際には、それ以上のものがあります...私はそれを正しくしていません。
Node.jsをまだ試す機会がなかったので、コメントできません。 RabbitMQに満足しています。
re:socket.io(私たちはwebsocketsを話しているのですか?)-これがブラウザー用である場合(上記の投稿が示唆するように)、RabbitMQにブリッジする可能性があります。つまり、RabbitMQはこれほど柔軟です。
RabbitMQは、必ずしもブラウザーのユーザーではなく、アプリケーション間でメッセージを渡す方法として使用されます。次に、たとえば受信したメッセージをブラウザーにプッシュするRabbitMQクライアントをnode.jsに実装できます。
例については http://www.rabbitmq.com/blog/2010/11/12/rabbitmq-nodejs-rabbitjs/ を参照してください。