2

次のようなトランザクションを行う Apache Camel に基づくミドルウェアがあります。

from("amq:job-input")
  to("inOut:businessInvoker-one") // Into business processor
  to("inOut:businessInvoker-two")
  to("amq:job-out");

現在、それは完全に機能します。しかし、100 TPS から 500 TPS にスケールアップすることはできません。私はもう

  1. コンカレント コンシューマ設定を上げ、空の businessProcessor を使用しました
  2. 構成された JAVA_XMX および PERMGEN

トランザクションを高速化します。

Active MQ Web コンソールによると、シナリオ 500TPS で処理待ちのメッセージが非常に多くあります。解決策の 1 つは、ActiveMQ をスケールアップすることだと思います。そのため、クラスターで複数のブローカーを使用したいと考えています。

http://fuse.fusesource.org/mq/docs/mq-fabric.html (セクション「トポロジー」) によると、クラスタリング モードで ActiveMQ を構成することは、非永続的なメッセージに適しています。私見、実行中のすべてのブローカーが同じストアファイルを使用するため、適切ではないことは事実です。しかし、ストアファイルを分離するのはどうですか？今なら可能ですよね？

誰でもこれを説明できますか？それが不可能な場合、永続メッセージの負荷を分散する最善の方法は何ですか?

ありがとう

4

5 に答える 5

1

2 つのマスター/スレーブ ペアを作成することで、永続的なメッセージの負荷を共有できます。マスターとスレーブは、データベースまたは共有ファイルシステムを介して状態を共有するため、そのセットアップを複製する必要があります。

2 つのマスター スレーブ ペアを作成し、2 つのペア間にいわゆる「ネットワーク コネクタ」を構成します。これにより、メッセージを失うリスクなしにパフォーマンスが 2 倍になります。

http://activemq.apache.org/networks-of-brokers.htmlを参照してください。

于 2015-03-10T13:33:54.723 に答える
0

コンシューマーを追加すると、ある程度役立つ場合があります (サーバーのコア/CPU の数によって異なります)。「Camel サーバー」が利用可能なすべての CPU をビジネス処理に利用しているポイントを超えてスレッドを追加することは意味がなく、生産性を高めることができます。

さらに ActiveMQ マシンを追加する必要がある可能性があります。ActiveMQ の「ネットワーク」を使用して、分離された永続ファイルを持つインスタンス間で通信できます。ブローカーを追加してネットワークに入れるのは簡単です。

道路に沿ってパフォーマンス テストを行い、ブローカが処理できる負荷の種類とキャメル プロセッサが処理できる負荷 (マシンが異なる場合) を確認してください。

永続的なメッセージングを行う場合、トランザクションも必要になる可能性があります。それらを使用していることを確認してください。

于 2013-08-14T22:23:33.803 に答える
0

この回答は、キャメルの詳細が追加される前のバージョンの質問に関連しています。

正確に何を負荷分散したいのか、またその理由はすぐにはわかりません。消費者全体のメッセージ? ブローカー全体のプロデューサー？どのような懸念に対処しようとしていますか?

一般に、ある種の地理的ユースケースに対処しようとしている場合、単一のブローカーが処理するには接続が多すぎる場合、または単一のブローカー (HA で構成されたブローカーのペアである可能性があります) の場合を除き、ブローカーのネットワークの使用を避ける必要があります。必要なスループットが得られません (90% の場合は得られます)。

ブローカー ネットワークでは、各ノードが独自のストアを持ち、ストア アンド フォワードと呼ばれるメカニズムを介してメッセージをやり取りします。これがどのように機能するかの説明については、ブローカーネットワークについてを読んでください。

ActiveMQ は、キューのサブスクライバー間でラウンドロビン方式でメッセージを均等に分散することにより、一種のロード バランサーとして既に機能しています。したがって、キューに 2 つのサブスクライバーがあり、メッセージ A、B、C、D のストリームを送信するとします。一方のサブスクライバーは A & C を受け取り、もう一方は B & D を受け取ります。

これをさらに一歩進めて、関連するメッセージをキューにグループ化し、1 つのサブスクライバーのみが一貫して処理できるようにする場合は、メッセージ グループを検討する必要があります。

于 2013-08-12T12:34:56.857 に答える
-1

最初のステップは、ActiveMQ から処理するワーカーの数を増やすことです。?concurrentConsumers=10これを行う方法は、開始 URI に属性を追加することです。デフォルトの動作では、1 つのスレッドのみがそのエンドポイントから消費するため、ActiveMQ でメッセージが山積みになります。ブローカーを追加しても役に立ちません。

第二に、あなたがやっているように見えることは、ステージド イベント ドリブン アーキテクチャ (SEDA) の恩恵を受ける可能性があります。SEDA では、処理はいくつかの段階に分割され、さまざまな数のコンシューマーを使用してスループットを均等にすることができます。ActiveMQ から消費するスレッドは、プロセスの 1 つのステップのみを実行し、Exchange を次のフェーズに引き渡し、入力キューからのメッセージのプルに戻ります。

したがって、ルートは 2 つの小さなルートとして書き換えることができます。

from("activemq:input?concurrentConsumers=10").id("FirstPhase")
    .process(businessInvokerOne)
    .to("seda:invokeSecondProcess");

from("seda:invokeSecondProcess?concurentConsumers=20").id("SecondPhase")
    .process(businessInvokerTwo)
    .to("activemq:output");

入力キューからのメッセージ消費率が出力率と一致するように、2 つのステージは異なる数の同時コンシューマーを持つことができます。これは、呼び出し元の 1 つが別のものよりもはるかに遅い場合に役立ちます。

メッセージの永続性が必要な場合は、エンドポイントseda:を別の中間エンドポイントに置き換えることができます。activemq:

最後に、スループットを向上させるために、呼び出し元自体をプロファイリングしてそのコードを最適化することにより、処理自体を高速化することに集中できます。

于 2013-08-13T10:07:49.080 に答える