現場のデバイスからメッセージを受信する状況に対処しています。これらのメッセージにはシーケンス番号がスタンプされており、これらのメッセージを元の順序で処理する必要があります。メッセージが失われることはめったにありませんが、不可能ではないので、それに対処するためのメカニズムが必要です。
私の実装はNServiceBusに基づいて構築されており、「HandleCurrentMessageLater」機能を使用して、メッセージが順不同で受信された場合にメッセージをキューの後ろにポップします。
これは、バックログを処理できるように、最終的にシーケンス内の次のメッセージを受信する場合にうまく機能します。
この場合、欠落しているメッセージに対処するためにどのようなオプションが必要ですか？私の最初の反応は、ある種のエージングアルゴリズムを実装することです。これは、設定された回数の試行の失敗などの後にシーケンス番号を増やすものですが、これを実行する必要があることの複雑さは少々圧倒的です。
誰かが同様の問題に直面し、彼らがそれをどのように解決したかを喜んで共有したことがありますか？
ありがとう
これはあなたがビジネスからのインプットを必要とするものであるように私には聞こえます。そのメッセージが取り返しのつかないほど失われたと見なすことができる時間制限はありますか？もしそうなら、そのような場合に取られるべきビジネスアクションは何ですか？そして、そのメッセージが最終的に受信されたが、タイムアウト後に発生した場合はどうなりますか？
佐賀で実装できるようなケース。メッセージが到着して順序が狂っている場合でも、HandleCurrentMessageLaterを呼び出しますが、タイムアウトを要求して、ビジネスで承認されたタイムアウト後もこれらの条件が当てはまる場合は、補正アクションを実行して、残りのバックアップされたメッセージを処理できます。
または、別の解決策が考えられます。メッセージを元の順序で処理する必要があるとのことですが。これが実際にどのような影響を与えるかについては詳しく説明しませんが、これは高レベルのビジネス要件のように聞こえますが、技術的な要件ではありません。言い換えれば、それは企業がそれを見たい方法ですが、それは実際に起こる方法である必要はありません。おそらく、順序どおりのメッセージを正常に処理し、収集されたデータが有効なシーケンス番号を示す値をインクリメントすることもできます。メッセージが順不同で到着した場合でも、ソフト処理は可能ですが、シーケンス番号は増加しません。
したがって、基本的にメッセージ1〜5を受信し、通常どおりに処理します。次に、7-10（6はスキップされました）を受け取り、それらを処理しますが、ValidSequenceNumberはまだ5です。次に＃6が到着したら、それを処理し、追いつくために補正アクションを実行し、ValidSequenceNumberは10になります。佐賀は、この種のロジックを実装するのにも適しています。
NSB sagasを使用する場合、DavidBoikeは正しい答えを持っています。別のオプションを追加したいのですが。メッセージが短時間で生成される場合、デバイスはNSB機能を使用して、複数の論理メッセージを1つのトランスポートメッセージにバッチ処理できます。SendまたはPublishオーバーロードを使用するだけで、IBus複数のメッセージパラメータが必要になります。これらのバッチは順番に処理されることが保証されています。
すべてのメッセージを確実に配信する必要があり、伝送チャネルの信頼性が低い場合は、確認応答と再送信のメカニズムが必要になります。これは次のようになります。
通常の流れ：
失われたメッセージ：
これには明らかに、サーバーからクライアントへの伝送チャネルを使用した双方向通信が必要です。
この問題は、シーケンス送信を保証するTCPプロトコルで詳細に解決されています。TCP再送信の内部を確認することをお勧めします。