画像処理アーキテクチャの設計に関するアドバイス

Question

私はストックスタンダードのASP.NET MVC 3 Webアプリケーション（IIS 7でホストされています）で作業しています。このサイトでは、ユーザーが写真などをアップロードすることができます。

次のようにアップロードプロセスは次のとおりです。

1. ユーザーが自分のPCからファイルを選択するためのウィジェット（現在plupload）を利用します。
2. AJAX呼び出しが（Request.Files）
3. Serverは各リサイズ写真は、現時点ではAmazon S3の

にアップロードされ

回の写真N量をリサイズするHTTP POSTの画像で、私のサーバーに起こります上記は.NET 4.0のTPLを使用して「ファイアアンドファー」技術で実装されています。

上記をより柔軟で堅牢にしたいと考えています。たとえば、画像処理が失敗した場合（GDIを使用している可能性が高いため）、S3がダウンした場合（つまり、発生した場合）、ユーザーはそのことを知ることができません。

私は、WindowsサービスとしてWCFサービスをホストすることを考えています.WCFサービスは、イメージ用のフォルダをポーリングします。

私のメインのウェブサイトは単に画像を「監視」フォルダにFTPで転送するだけで、サービスは画像処理とアップロードを処理します。

ユーザーは写真が完了したことをすぐに通知する必要はありません。言い換えれば、今は「あなたのイメージが処理されており、まもなく利用可能になります」というメッセージが表示されます。サービスが必要であり、まとめると

：

1. リサイズ画像
2. アップロード画像をS3
3. 読み取り/書き込みにデータベースへ
4. "再試行" する能力は、画像に

を失敗しました

アドバイスはありますか？ FileSystemWatcherはいいですか？

Answer 1

私の現在のプロジェクトでは、比較的成功したFileSystemWatcherを使用してデータ処理を担当する同様のミドルウェアサービスを実装しました。覚えておくべきこと：

1. コア処理にはある種のキューイングを実装してください。同時に100の画像変換プロセスを開始することは良い考えではありません。 ThreadPoolの使用を検討してください。
2. FileSystemWatcherは、ファイルが作成されるとすぐに通知を行います。書き込みがロックされている可能性があります。定期的なチェックを実行して、処理を開始する正しい瞬間を判断する必要があります。おそらく、メインループとキューを使用しています。
3. 細かいステータスの変更（file_created、file_processing、file_processed、file_uploadingなど）を追跡します。デバッグには本当に必要になるかもしれません。

これは役に立って幸運を願っています。