私たちが構築しているシステムは、外部フィードを介してデータを受信しています。私たちの仕事は、このデータを複数のサービスに配布し、計算を実行して、結果を他の場所に転送することです。これは、典型的なパブリッシャー/サブスクライバーの状況です。必要なのは、非常に低遅延のメッセージングです。MSMQのようにメッセージを永続化する必要はありません。
RabbitMqは、ソフトリアルタイムメッセージ配信に十分な速度ですか？ベンチマークはありますか？TIBCO Rendezvousの代わりに使用するのは良い考えですか？他にオープンソースのソフトリアルタイムメッセージングの代替手段はありますか？
ありがとう。
（私はrabbitmq開発者です。）
ウサギは、負荷が軽い場合、ネットワークカードやCPU速度などに応じて、通常100〜400マイクロ秒のオーダーの遅延が発生します。読み込みが少し重くなると、内部バッファリングが表示され始め、レイテンシが少し上がります。帯域幅の使用（1秒あたりのメッセージ数、1秒あたりのバイト数）が高くなり始めるまで、1ミリ秒の遅延を安全に期待できます。当然のことながら、永続性が導入されると、レイテンシーも上昇します。
ベンチマークに関して、ここでの最大の問題の1つは、アプリケーションにとって何が重要かを定義することです。Javaクライアントに含まれている、非常に単純なポイントツーポイントおよびpub-subのレイテンシーとスループットの測定例がいくつかあります。問題がある場合は、rabbitmq-discussリストで質問してください。これらは実際のアプリケーションとの関連性をあまり測定しませんが、レイテンシーまたはスループットのマイクロベンチマークに関する懸念を和らげるのに役立つ可能性があります。
最後に、最近利用できる多くの優れたオープンソースメッセージングおよびメッセージング関連システムがあります。AMQPだけの世界では、RabbitMQの他に、QpidとOpenAMQもあります。Javaに制限できる場合は、優れたオープンソースのJMSサーバーもあります（多くの人がActiveMQで成功しています）。RubyやPythonシステムにも、多くの軽量システムが登場しています。これらのシステムは、キューイングのみに集中する傾向があり、AMQPが提供する柔軟なルーティング機能を備えていない傾向があります。
CPUごとに1秒あたり数万のメッセージを達成できるはずです。たとえば、標準テストの1つは、JavaクライアントからクアッドコアCOTS Debianボックスで実行されているサーバーに1秒あたり25kのメッセージをプッシュし、クライアントに戻します。クライアントとサーバーは同じボックスで実行されているため、サーバーで1秒あたり5万件のメッセージが処理され、クライアントで1秒あたり5万件のメッセージが処理されます。より多くのコアを備えた専用ボックスでサーバーを実行することで、より高いレートを得ることができます。バイト/秒に基づくレートについては、rabbitmq-discussメーリングリストでお問い合わせください。
アレクシス
私があなたのシステムについて考えることができる最良の解決策はZeroMQです。
それはあなたが必要としないとあなたが言った永続性を持っていません、そしてそれは非常に速くそして簡単に使うことができます。
これはAMQP実装ではありませんが（あなたも必要ないようです）、このガイドに記載されているとおりです。
ØMQ（ZeroMQ、0MQ、zmq）は、埋め込み可能なネットワークライブラリのように見えますが、同時実行フレームワークのように機能します。インプロセス、インタープロセス、TCP、マルチキャストなどのさまざまなトランスポート間でメッセージ全体を伝送するソケットを提供します。ソケットは、ファンアウト、pub-sub、タスク分散、要求/応答などのパターンでNからNに接続できます。クラスター化された製品のファブリックになるのに十分な速度です。その非同期I/Oモデルは、非同期メッセージ処理タスクとして構築されたスケーラブルなマルチコアアプリケーションを提供します。多数の言語APIがあり、ほとんどのオペレーティングシステムで実行されます。