2

NServiceBus はメッセージが特定の順序で処理されることを保証しないため、送信者から送信された順序でメッセージを処理する方法を見つけようとしています。

送信者は、createOrder および reviseOrder コマンドを発行するオーダー システムです。送信者は、ユーザーが同じ注文に複数のリビジョンを送信できるようにするため、リビジョン 4 とリビジョン 3 を同時にキューに入れることができます。各リビジョンにはリビジョン番号とそれに関連付けられた理由コードがあり、ビジネス ロジックを駆動するため、リビジョンまたは少なくともその理由部分を無視することはできません。

私が持っていたいくつかのアイデアを以下にリストします-

  1. リビジョン番号を宛先レコードとともに保存します。送信者は、各リビジョン メッセージでリビジョン番号を送信します。ハンドラーは送信者と宛先のリビジョン番号を比較し、一致する場合はレコードが更新され、そうでない場合はメッセージがキューの最後に置かれます。このアプローチでは、リビジョン 2 メッセージが失敗してエラー キューに入ると、リビジョン 3 は処理されません。

  2. 送信者は、すべてのリビジョン メッセージですべてのリビジョンのすべての理由コードの履歴を送信します。そのため、リビジョン 2 メッセージが失敗した場合、リビジョン 3 メッセージにすべての理由コードが含まれます。これらの理由コードは宛先に記録されますが、以前のリビジョンの理由コードに関連付けられたビジネス ロジックは発生しない可能性があります。

このシナリオをどのように設計しますか?
また、失敗したリビジョン メッセージを処理する方法についてのアイデアはありますか?

いくつかのガイダンスは本当に感謝しています。

ありがとう。

4

1 に答える 1

9

NserviceBus に関する基本的なガイドラインの 1 つは、すぐに使用できるように、順序が問題にならない方法でシステムを構築する必要があるということです。以前にNSBを使用して注文システムを構築したことがあると言いましたが、それを行うことにした方法は次のとおりです。

  • すべてのメッセージにシーケンス番号を追加する
  • 受信側で、シーケンス番号が最後に確認された番号 + 1 であることを確認します
  • 第 2 レベルの再試行を有効にします (順序が間違っている場合は、正しいメッセージが受信された後に再試行されることを願っています)。

これは一般的にはかなりうまく機能しますが、何かがあまりにも長い間故障していて、手動での介入が必要な場合は、少しうまくいかないことがあります。

あなたのシナリオでは、おそらくもっと良い方法があります。注文に対して行われた改訂内でのみ注文したい場合。注文配送を必要としない方法でこれを構築できると思います。

  • リビジョンで変更できるすべてのフィールドにリビジョン番号を追加します
  • メッセージ内のリビジョン番号が >= データベース内の最後のリビジョンである場合にのみ、フィールドを更新します

これには多くの利点があります。

  • 順序に依存しない
  • 受信者が各メッセージを 1 回処理するだけで済むため、負荷が軽減されます。
  • 1 つのメッセージに問題がある場合にすべてを停止しないことで、エラーを適切に処理します。

ただし、次の欠点があります。

  • データベースに追加された複雑さ
  • データベースを見ると、ユーザーが行った編集の一部しか含まれていない可能性があります。
  • rev2 エラーが発生し、rev3 が正しく処理された場合、一部のユーザーの編集は表示されませんが、一部は表示されます。
于 2013-09-07T01:25:32.097 に答える