後ですべてのメッセージを再生できるように、送信するメッセージのコピーを保存する必要があるアプリケーションを構築しています。これは、メッセージの処理が開発の過程で劇的に変化するため必要ですが、データはリアルタイムの観測データであるため、できるだけ早く取得する必要があります。これに直接対処する組み込み機能が見つからないようです。データを永続化するためのカスタム ツールを作成することはできますが、そもそも NServiceBus を使用する目的と矛盾しているようです。私が検討しているいくつかのオプション：
ターゲット バスの ForwardReceivedMessagesTo 機能を使用してアーカイブ キューを作成し、このアーカイブ キューを入力キューとして使用して、Replayer ツールが実行されるたびにメッセージをターゲット バスに転送する単純なアプリケーションを構築します。これによりアーカイブ キューがクリアされるため、最初に mqbkup ユーティリティを使用してバックアップする必要がありますが、これはリプレイ プロセスの一部として自動化できます。または、2 つの交互のアーカイブ キュー (1 つは新しいメッセージを取り込み、もう 1 つは再生用) を使用すると、これを解決できます。
パブリッシュ/サブスクライブ モデルを使用し、アーカイバにターゲット キューをサブスクライブさせて、メッセージをアーカイブ キューに配置します。上記のような Replayer ツールは、アーカイブ キューを入力キューとして使用し、メッセージをターゲットに転送できます。これにより、アーカイブ キューもクリアされ、上記の解決策のいずれかが必要になります。
MassTransit の人々は、キュー間のコピーを可能にするBusDriverと呼ばれるものについて言及していますが、それ以上のことは見つかりません。
私の主な関心事は、データが失われる可能性が最も低いアプローチを選択することです。観察が行われると、狭い時間枠の外では二度と行うことができないからです。これは一般的な問題のようですが、簡単な解決策を見つけることができないようです。提案？
更新ジャーナリングされたターゲット キューを使用することにしました。アーカイバにジャーナルを入力として使用させ、メッセージをデータベース (ファイルベースの場合もあります) に保存し、そのデータベースからターゲット キューへのメッセージを再生できるようにします。ジャーナル キューからターゲット キューにメッセージをコピーするツールを作成することは可能ですが、実際の問題は、実際的な観点からは、ジャーナル キューを管理することです。簡単にバックアップすることはできません (mqbkup NServiceBus レベルの抽象化に固執したい場合は、キューで非破壊的に操作するために、MSMQ ベースのツールを作成する必要があります。最終的に、MSMQ はトランスポートであり、メッセージのストアではないため、そのように扱う必要があります。