1

ActiveMQ で Apache Camel を使用しており、保証されたメッセージ配信を実装したいと考えています。

Camel in Action 本と Apache Camel Developer's Cookbook を読んでいます。

ここの誰かが私のアプローチについてアドバイスしてくれることを願っています。コードサンプルを求めているわけではありません。

私が思い描いた実装方法は次のとおりです。

1. Message is received on an endpoint
2. I inspect the message
3. I use the Wiretap pattern to drop it immediately on my "GuaranteedMessages" queue if the message asks for guaranteed delivery
4. I route the message to its proper destination
5. If no exceptions were encountered, I remove the message manually from the "GuaranteedMessages" queue

簡単に聞こえます。ただし、キャメルの「デッドレターチャネル」パターンについて読んでいます。

このパターンの実装を使用するという私の理解は、各 (保証された) メッセージを「GuaranteedMessages」キューに自動的にドロップする代わりに、そのアプローチをドロップし、代わりに再配信オプション (最大試行回数、指数関数的遅延、再配信遅延など) を設定することを意味します。 . 次に、Camel に頼って再配信を試み、それが通過しない場合はデッド レター チャネルの遅​​延にドロップします。

次に、この配信不能キューをソースとして使用する別のルートを作成します。繰り返しますが、同じパターンになります。成功しない場合は、メッセージを配信不能キューに送り返します。

これは本番システムの現実的な実装のように思えますか?

代わりに、すべての受信メッセージ (保証する必要がある) を自分の "GuaranteeMessage" キューにドロップすることにした場合、後でその特定のメッセージをキューから手動で削除できると信じるのは現実的ですか? 私の理解では、キューを手動で参照し、任意の数のメッセージを繰り返し処理し、そのメッセージを手動で消費する必要があります。そのようなアーキテクチャが実際にどれほどスケーラブルかはわかりません。

4

1 に答える 1

1

おそらく、最終的な宛先は別の ActiveMQ キューではなく、例外によって可能なものです。盗聴の考え方は、DLQ を使用する場合と機能的に同じであるため、正常に動作する Camel 機能を使用して、できるだけ多くの作業を行うこともできます。

ただし、2点。最初に、DLQ ではなく明示的なキューを使用して、再試行が必要なメッセージを保持します。これは、ブローカーごとに DLQ が 1 つしかなく、予期しないものが表示されないようにするためです。

次に、再試行キューからメッセージを取得して再送信するだけの場合は、再試行回数を増やして Camel 例外処理を遅らせてみませんか? そうすれば、再試行キューには、おそらく手動の介入が必要なメッセージだけが含まれます。したがって、メッセージが再試行キューにある場合は、根本的な原因が何であれ手動でチェック/修正し、メッセージを手動で入力キューに移動します。

于 2014-07-14T12:18:08.347 に答える