3

非常に高速（> 100,000 /秒）で入力されるJMSキューがあります。

同じエンティティに関連する複数のメッセージが毎秒存在する可能性もあります。（エンティティに対するいくつかの更新。更新ごとに異なるメッセージとして表示されます。）

一方、このメッセージを処理して他のアプリケーションに送信するコンシューマーが1つあります。

現在、消費者は着信メッセージの速度に対応できないため、セットアップ全体の速度が低下しています。

コンシューマーがメッセージを処理する速度にはSLAがあるため、プロセスを高速化するために複数のコンシューマーを並行して動作させるというアイデアを検討してきました。

だから、私がやろうと思っているのは

  • キューで独立して動作する複数のコンシューマー。
  • 各消費者は自由にメッセージを取得できます。
  • メッセージを取得したら、エンティティの最新バージョンであることを確認してください。このため、一部、このエンティティを処理するアプリケーションで確認できます。
  • 最新でない場合は、バージョンを上げて再試行してください。

私はこれまで統合パターン、JMSドキュメントを調べてきましたが成功しませんでした。

既知のAPI、Javaの世界のパターンとともに、よりエレガントな方法でこの問題に取り組むためのアイデアを歓迎します。

4

3 に答える 3

2

ActiveMQ は、「メッセージ グループ」と呼ばれる概念でこの問題を解決します。JMS 標準の一部ではありませんが、いくつかの JMS 関連製品は同様に機能します。基本的な考え方は、各メッセージを「グループ」に割り当てることです。これは、関連し、順番に処理する必要があるメッセージを示します。次に、各グループが 1 つのコンシューマーにのみ配信されるように設定します。したがって、グループ間で負荷分散が行われますが、グループ内での順序どおりの配信が保証されます。

于 2012-12-31T19:42:13.893 に答える
0

ほとんどの EIP フレームワークと ESB には、カスタマイズ可能なリシーケンサがあります。エンティティの量が多すぎない場合は、エンティティごとにキューを作成し、最初に再シーケンスすることができます。

于 2012-12-31T18:56:53.270 に答える
0

これを解決する方法に興味がある人のために：

質問は JMS に関するものなので、 Apache Camel の Web サイトの例を見てみましょう。

このアプローチは、 CBRやSelective Consumerなどの他のパタ​​ーンとは異なります。これは、コンシューマーが処理すべきメッセージを認識していないためです。これを実際の例に当てはめてみましょう。

ERP によって処理される注文を送信する注文管理システム (OMS) があります。その後、注文は 6 つのステップを経て、各ステップで Order_queue にイベントが発行され、新しい注文のステータスが通知されます。ここでは特別なことは何もありません。OMS はそのキューからイベントを消費しますが、各注文のイベントを発行されたのとまったく同じ順序で処理する必要があります。1 分あたりに発行されるメッセージのレートは、コンシューマのスループットよりもはるかに大きいため、時間の経過とともに遅延が増加します。

ソリューション要件:

  • キューのサイズを適切な量に保つために必要な数のコンシューマーを含めて、並行して消費します。
  • 各注文のイベントが同じ発行順序で処理されることを保証します。

実装:

OMS 側 注文を ERP に送信する OMS プロセスは、特定の注文のすべてのイベントを処理するコンシューマーを決定し、注文と共に受信者名を送信します。このプロセスは、受信者が何であるかをどのように認識していますか? さまざまなアプローチを使用できますが、非常に単純なラウンド ロビンを使用しました。

ERP では、注文ごとに受信者の名前を保持しているため、目的の受信者に配信されるメッセージを設定するだけです。

OMS Consumer では、4 つのインスタンスをデプロイしました。それぞれが異なる受信者名を使用し、メッセージを同時に処理しています。

データベースというもう 1 つのボトルネックが発生したと言えます。しかし、注文明細行には並行性がないため、これは当てはまりません。

欠点の 1 つは、注文を ERP に送信する OMS プロセスが、作業中の受信者の数を把握しておく必要があることです。

于 2014-07-31T15:00:49.783 に答える