1

多数のメッセージを処理する必要があるという要件があります。これらのメッセージは、別のプロセスによって DB テーブルに挿入されます。私がしなければならないのは、DB で新しいメッセージをチェックし、構成に応じて対応する顧客に電子メールまたは http で送信することだけです。メッセージの数は常に数千に達する可能性があり、顧客の数は約 1000 です。

生産者と消費者が機能する方法でこれを設計する予定です。プロデューサー スレッドが DB をポーリングして新しいメッセージを探し、それらを Queue に入れるように、ワーカー スレッドがこれらのメッセージとプロセスを読み取ります。

最初は、JMS がこの要件に適したソリューションであるように見えました。ただし、次のシナリオを考えると、この要件に適した Threadpool を使用して、ExecutorService のような代替手段があるかどうかを探しています。

  1. 1 つのメッセージ配信が失敗した場合、少なくとも 24 時間は何度か再試行する必要があります。
  2. 顧客に対して 1 つのメッセージ配信が失敗した場合、他のメッセージ配信もすべて失敗する可能性があります。したがって、その顧客への次のメッセージを処理する前に、最初のメッセージを送信する必要があります。

つまり、すべての顧客のすべてのメッセージに対して 1 つのキューがある場合、1 つのメッセージが失敗すると、他のメッセージは処理されません。

これをどのように処理するのが最善かについて誰かが提案してもらえますか?

前もって感謝します。

4

2 に答える 2

1

Apache Camelを真剣に検討する必要があります。多数の組み込みコンポーネント (SQL、JMS、SMTP、HTTP、ファイルなど) を使用して、すべてのスレッド化、生成、および消費を処理し、コンシューマー/プロデューサーに関する用語は統合のキャメル ビューと一致します。

あなたが説明したようなものを実装するのは次のように簡単です：

from("sql:select * from table")
  .to("jms:myQueue");

エンドポイントのリストを見てください

于 2010-12-14T01:26:21.947 に答える
0

汎用 JMS を使用すると、再試行ロジックを比較的簡単に実装できます。トランザクションを使用せず、メッセージに再試行属性を割り当て、再試行ごとに増分し、再試行時にリスナーで一時停止し、制限を超えたら終了します。

顧客ごとのキューは、最も単純な構成です。動的キューは顧客に役立つ場合があります。顧客ごとにキューとリスナーを動的に作成します。

実際にデータベースを確実にポーリングすると、より多くの課題が発生する可能性があります。

于 2010-12-14T06:01:41.100 に答える