0

状況を説明してみましょう。

キューまたはトピック (JMS 用語) のいずれかであるメッセージング システムを組み込む予定です。

1 ) Producer/Publisher :サービス A があります。A はメッセージを生成し、Queue/Topic に書き込みます。

2 ) Consumer/Subscriber :サービス B があります。B はキュー/トピックからメッセージを非同期に読み取ります。次に、B は Web サービスを呼び出し、メッセージをそれに渡します。Web サービスがメッセージを処理するのにかなりの時間がかかります。(このアクションはリアルタイムで処理する必要はありません。)

メッセージ ブローカーは Tibco です

私の意図は次のとおりです。Aからのメッセージの処理を逃さないことです。処理が初めて（おそらくバッチとして）失敗した場合に備えて、後で再処理します。

質問:

Web サービスを呼び出す前に、メッセージを DB に書き込むことを考えていました。呼び出しが成功した場合は、メッセージに処理済みのマークを付けます。それ以外の場合は失敗しました。その後、cron ジョブで、最初に失敗したすべての要求を処理しました。

DBへの書き込みはこれを行う典型的な方法ですか?

4

4 に答える 4

0

コールバックに失敗したので、キューに入れ直して、それをピックアップして再試行することができMessageますConsumer/Subscriber。Webサービスの問題が原因で失敗し、X時間待ってから再試行する場合は、Webサービスが後日呼び出されるようにスケジュールを設定するか（ ScheduledExecutorServiceMessageを調べてください）、そのまま実行できます。説明し、いくつかのデータベースエントリでcronジョブを使用します。

メッセージごとに1回だけ再試行する場合は、各のカウンターとして、Messageまたは内の内部カウンターを保持します。Map<Message, Integer>Message

于 2013-02-12T19:06:35.740 に答える
0

カスタム ソリューションを構築する (例 2) のではなく、既にお持ちの EMS プラットフォーム (例 1) を利用することは興味深いかもしれません。

しかし、それはすべて実装言語に依存します:

例 1 - EMS が「キーパー」: TIBCO BusinessWorks でこのような問題を解決する場合、BW の「JMS トランザクション」機能を使用します。EMS の読み取りと WS の呼び出しを同じ「グループ」に含めることで、両方を適用するか、まったく適用しないかを指定できます。何らかの理由で呼び出しが失敗した場合、メッセージは EMS に返されます。このソリューションには 2 つの問題があります。BW がない可能性があり、最初に失敗した操作によって、残りのバッチ プロセスがすべてブロックされます (これが望ましい動作である可能性があります)。参考までに、「純粋なJava」でそのような機能を使用できることは理解していますが、試したことはありません: http://www.javaworld.com/javaworld/jw-02-2002/jw-0315-jms.html

例 2 - DB が「キーパー」 : 「DB」メソッドを使用する場合、キュー/トピックの顧客は挿入データを DB に継続的にドロップし、すべてのレコードは実行されるタスクを表します。これは、すべての統合ミドルウェアが容易にすることを目指している単純な「マッピング エンジン」の問題に非常によく似ています。これは、カスタム Java コードと複数のスレッド (DB インサータ、WS ジョブ ハンドラなど) から、EAI ミドルウェア (BW など) や BPM エンジン (TIBCO にはそのための多くのソリューションがあります) まで、何でも解決できます。は他のベンダーでもあります... ご存じのとおり、EMS は JMS 標準実装です。

于 2013-02-14T02:31:14.647 に答える
0

「保証された配信」が目的で構築されているため、組み込みのEMS（およびJMS）機能を使用することをお勧めします;）-データベースはまったく必要ありません...

最初の決定は次のようになることに注意する必要があります。

  • 順番に配達する必要がありますか？(その場合、1 つの JMS セッションとクライアント Ack モードのみを使用する必要があります)
  • どのくらいの頻度で再試行しますか? (その Web サービスで処理できなかったメッセージの無限ループを作成しないため)。

これは、使用するクライアントの種類に依存しません (TIBCO BW または MDB の Java onMessage() など)。

「順序どおり」の配信の場合: shure を 1 つだけ作成します。1 つの JMS セッションがメッセージを処理し、クライアント確認モードを使用します。メッセージを正常に処理した後、JMS API の「acknowledge()」メソッドを呼び出すか、TIBCO BW で​​「commit」アクティビティを実行してメッセージを確認する必要があります。

エラーが発生した場合、メソッドの承認を実行しないため、メッセージは再配信のためにキューに戻されます (JMS ヘッダーで再配信された回数を確認できます)。

EMS の Explicit Client Acknolwedge モードを使用すると、順序が重要ではなく、メッセージを処理するためにいくつかのクライアント スレッドが必要な場合にも同じことができます。

メッセージが処理される頻度を制御するには、次を使用します。

  • EMS キューの最大再配信プロパティ (たとえば、他のメッセージを滞らせないようにするために、x 回の再配信後にデッド レター キューにメッセージを入れることができます)
  • 再配信の遅延。再配信の間に「一時停止」を入れます。これは、Web サービスがクラッシュ後に回復する必要があり、再配信によって同じメッセージが何度も何度も頻繁に殺到しない場合に役立ちます。

それが役立つことを願っています

乾杯セブ

于 2013-03-02T10:13:48.440 に答える
0

大雑把に言えば、それがテクニックですが、すぐに使用できるソリューションが利用できる可能性があります。一般的な ESB ソリューションは、信頼性の高いメッセージングをサポートしています。MuleESBまたはApache ActiveMQも参照してください。

于 2013-02-12T19:12:10.443 に答える