1

キューに入れられた長時間実行されるプロセスを処理するサービスを構築する最善の方法は何ですか? たとえば、これは私たちがやろうとしていることです

  1. ユーザーが 401k データを Web にアップロード
  2. データは処理キュー (データベース テーブル) に入ります
  3. 401k が処理されます (クライアントごとに数分かかる場合があります)
  4. ユーザーは、401k が受け入れられたことを電子メールで通知されます

確かにこれを処理するサービスを作成できますが、サービスが失敗した場合はどうなるでしょうか? 誰かにどのように通知されますか? 例外がある場合はどうなりますか？また、このサービスは、ユーザーが開始しない他のプロセス (電子メールの送信など) を処理する必要があります。

熟練した .NET 開発者のチームがありますが、私たちの経験はすべて、タスク スケジューラによって起動される Web/クライアント アプリまたはコンソール アプリに関するものです。

4

2 に答える 2

1

System.MessagingこのタスクにはMSMQ ( ) の使用を検討してください。おそらく次のような流れです。

  • ユーザーが Web サイトにデータをアップロードします。
  • データは MSMQ に書き込まれます。
  • 間隔nで、Windows サービスは次の待機中のメッセージをキューからピーク/読み取ります。
  • 作業はサービスによって行われ、データが DB に書き込まれ、顧客に通知するために別のメッセージが別のキューに送信されます。
  • 別のサービスが 2 番目のキューからピーク/読み取りを行います。必要に応じて顧客に電子メール/通知を送信します。この 2 番目のキューは、SMTP の停止などを処理するために必要であり、1 番目のキューとは別に管理できることを提案します。

潜在的な障害に関する他の懸念は、さらに別のサービスである可能性や、Web サイトのポーリング メカニズムである可能性があります。最後に処理されたメッセージの日時の DB を読み取ります。「待機中」の項目数を読み取ります。数が満足のいくものでない場合は、管理者/顧客/などに電子メールを送信してください。必要に応じて。

MSMQ を使用すると、プル システムを使用できるようになり、データベースに対してnごとにポーリングすることで、データベースとネットワークに負担をかける必要がなくなります。メッセージ送信はすべてトランザクションであるため、メッセージの紛失や未承認について心配する必要はまったくありません。

@ジェス：ベースをカバーしようとしていることを理解しました。適切なキューは、リクエストでデータベースを叩かないという点で役立ちます。これが問題になるかどうかは、アプリ/プロジェクト/顧客の規模によって決まります。実際、これをすべて Page_Load の 1 つの .aspx に入れることもできましたが、よく知っているはずです。

Re:やり過ぎ。ダウンタイムについていくつかの懸念があり、そのようなアプリがこれをどのように処理できるかという質問を「読みました」。すぐに使用できる Web サービスは、次のことを行いません。

  • 作業の出力を保存するために DB に依存しているため、DB の停止を適切に処理します。「キャッチャー」「ワーカー」「リザルト」が一挙に登場。これは本当に DMZ に属しますか? 注記 1: イントラネットではなく「Web」。

  • web+worker ノードを追加せずにスケーリングします。

この推奨される解決策には、次のものが含まれます。

  • MSMQ には独自のストレージ実装があるため、キューイングと配信順序についてアプリ データベースに依存しません。これは Windows の一部であり、サービスとして実行されます。MSMQ がダウンしている場合は、Windows がダウンしているか、セキュリティが正しく構成されていません。

  • 非同期処理。Web 層は、単純に要求を「キャッチ」し、キューに「入れる」ことができます。それでおしまい。スレッドのスピンアップやアプリケーション データベースへの依存はありません。他のユーザーからの要求を受信するジョブに戻ることができます。ユーザーは忙しい一日の遅れを「感じる」必要はありません。

  • スケーラビリティ。Windows サービスを 1 台以上のマシンに展開して機能させることができます。

  • 作業の分離: 401k 処理、電子メール送信、要求処理 + 認証はすべて個別のモジュールで行われます。

  • セキュリティ - これがイントラネット ソリューションかインターネット ソリューションかは 100% 明確ではありません。インターネットに公開されている場合は、DMZ から内部アプリケーションにメッセージを送信する方法を検討してください。オープンなインターネットからアプリケーション DB への読み取り/書き込みアクセス権を持つことを正当化できますか? ある種のファサードを考えてみましょう。キューはこれを提供します。

于 2010-09-05T05:35:08.497 に答える
0

エクスペリエンスが Web アプリである場合は、Web アプリで行います。独自の処理ではなく、Web サービスのコンテキスト内で処理を実行できます。

編集

どうやら私は十分に明確ではありませんでした。IIS は ASP.NET と静的コンテンツを提供しますが、データベース内のジョブを処理するポーリング スレッドをホストする理想的な場所でもあります。内部 Web ページに表示できる静的変数を更新でき、IIS が提供するすべてのログ、リセット、およびその他のインフラストラクチャの恩恵を受けることができるため、私はこれを理想的と呼んでいます。これにより、1 つのスレッドを実行するためだけに別のサービスを作成し、そのソリューションのコストを処理する必要があるという複雑さがすべて回避されます。

私はこれを数回行いましたが、良い結果が得られました。

于 2010-09-05T08:25:32.040 に答える