4

基本的に、ワーカー ノード間でタスクを分散する 1 つのマスター ノードがあります。ワーカーの数は変更される可能性があります。つまり、サーバー側でワーカーをハードコーディングできませんでした。マスターはタスクをキューに送信し、ワーカーの 1 つがこのタスクを取得して処理し、結果を返します。最も重要な側面は、低レイテンシです。ワーカー ノードでの通常の処理時間は約 100 ～ 300 ミリ秒です。これは、メッセージング システムが処理時間に大幅な遅延を追加しないことを意味します。

現在、リクエストとレスポンスの JMS パターンを調べています。これは、マスターがタスクを共有キューに送信し、ワーカーがキューからタスクを取得して、マスター ノードがリッスンする別のキューに結果を送信することを意味します。マスターは応答を要求と関連付けます。

残念ながら、JMS はシステムに遅延をもたらす可能性がありますが、これは受け入れられません。おそらく、他のソリューションを検討する必要がありますか？RabbitMQ、JGroups、ZooKeeper などですか?

ここで JMS が適している場合、最速の JMS ブローカーをお勧めできますか? 現在、私はActiveMQを見ています

ソリューションのもう 1 つの要件は、クラウドで動作できることです。

4

3 に答える 3

1

JMS ベースのソリューションでは、すべてのベンダー (Rabbit、Hornet、ActiveMQ など) が高スループットのために使用する固有のメッセージ バッチ処理手法が使用されているため、低レイテンシーを保証することはできません。IBM や Mule などのベンダーは、このジョブ向けの特定の低レイテンシー製品をリリースしています。

ただし、すべては負荷と生成されるタスクの数、および消費するワーカーの数に依存します。したがって、チューニングを使用すると、パーソナライズされた数値を取得できます。

LMAX ディスラプターに基づく CoralQueue は一見の価値があります。

于 2015-03-31T03:22:10.343 に答える
0

ここ [1] をご覧ください。Rabbitmq には優れたパフォーマンスに関する記事があり、レイテンシーについて説明しています。

簡単に要約すると、Rabbitmq はストレスの多い状況で 400 ミリ秒の遅延値を取ることができると言わざるを得ませんが、通常、送信レートが低い場合は 40 ミリ秒以下になります。ご覧ください (試行された送信レートとレイテンシのグラフ)

ところで、ネットワーク遅延も考慮に入れる必要があります。このベンチマークは、ローカルホストのパフォーマンスを示しています。

[1] http://www.rabbitmq.com/blog/2012/04/17/rabbitmq-performance-measurements-part-1/

于 2012-09-26T12:04:38.980 に答える