2

このアーキテクチャ ( http://www.devx.com/enterprise/Article/39015 )に基づいて、MSMQ を使用して Reliable WCF Service を実装しようとしています。

キューが使用できない場合、メッセージが失われる可能性があります (クラスターがゼロ ダウンタイムを提供しない場合でも)。

簡単な注文処理ワークフローを見てみましょう

  1. ユーザーがクレジット カードの詳細を入力して支払いを行う

  2. アプリケーションは、支払いゲートウェイから成功の結果を受け取ります

  3. アプリケーションは、WCF MSMQ バインディングによるバックエンド サービスへの「ファイア アンド フォーゲット」/「一方向」呼び出しとしてメッセージを送信します。

  4. ユーザーは「成功」ページにリダイレクトされます

  5. メッセージはリモート トランザクション キュー (Windows クラスター) に格納されます。

  6. バックエンド サービスはメッセージをデキューして処理し、複雑な注文処理ワークフローを完了して、その結果、確認メールをユーザーに送信します。

例外として、すべてが正常に見えます。

すべての「一方向」通話がキューに配信されることをどのように保証できますか ユーザーはできるだけ早く結果の Web ページにリダイレクトする必要があるため、二重通信は当てはまりません。

ユーザーが「...支払いが行われ、注文の処理が開始されました。後で通知をメールで送信します...」という文言の「成功」ページを受け取ったが、メッセージ自体が失われた場合を想像してみてください。

ステップ 3 でどの程度の耐久性を実装できますか?

私が見ることができる可能な解決策の1つは

3a. トランザクションに関する記録を保持するためだけに、トランザクションの詳細が未完了としてマークされたデータベース レコードを作成します。このレコードは、メッセージがキューに保存されない場合に失われたメッセージを処理するための開始点として使用できます。

この投稿を読みました

トランザクション MSMQ について理解しておくべき主な点は、リモート キューへのトランザクション送信には 3 つの異なるトランザクションが関係していることです。

  1. 送信者はメッセージをローカル キューに書き込みます。
  2. 送信側マシンのキュー マネージャーは、ネットワークを介してメッセージを受信側マシンのキュー マネージャーに送信します。
  3. 受信側サービスはキュー メッセージを処理し、メッセージをキューから削除します。

しかし、説明されている問題は解決しません-WCF netMsmqBinding はローカルキューを使用してメッセージをリモートキューに送信しないことを知っているためです。

4

1 に答える 1

1

しかし、それは説明されている問題を解決しません-私が知っているように、WCF netMsmqBinding はローカルキューを使用してメッセージをリモートキューに送信しません。

実際、これは正しくありません。WCF を使用しているかどうかに関係なく、MSMQは常にローカル キューを介してリモート キューに送信します。

メッセージをリモート キューに送信してから、サーバー管理のメッセージ キューを調べると、リモート キューのアドレスでキューが作成されていることが送信キューに表示されます。これは、自動的に作成される一時キューです。何らかの理由でリモート キューが使用できない場合、メッセージは使用可能になるまでローカル キューに置かれ、その後送信されます。

したがって、3 フェーズ コミットにより耐久性が提供されます。

  1. トランザクション的にメッセージをローカルに書き込む
  2. トランザクション的にメッセージを送信
  3. メッセージをトランザクション的に受信して処理する

たとえば、メッセージ処理がデキュートランザクションの範囲外で発生した場合や、処理が成功したかどうかを知ることができない場合 (バックエンド Web サービス呼び出しのタイムアウトなど) など、メッセージをドロップする場合があります。 )、そしてもちろん、処理が成功しない不適切な形式のメッセージを持つこともできますが、すべての場合において、これらのメッセージを設計できるはずです。

クラスタ化された環境でパブリック キューを使用している場合、msmq のクラスタ化によって複雑さが生じるため、失敗の可能性が広がる可能性があると思います (実際には使用していないのでわかりません)。

于 2013-01-11T21:10:05.533 に答える