關於圖像處理體系結構的設計建議

Question

我正在研究庫存標準的ASP.NET MVC 3 Web應用程序（託管在IIS 7上）。該網站允許用戶上傳照片等等。

上傳過程如下：

1. 用戶利用插件（目前plupload）從他們的PC選擇文件。
2. AJAX調用發生到我的服務器，在HTTP POST圖像（Request.Files）
3. 服務器重新調整
4. 每個大小的照片被上傳到亞馬遜S3

目前的時代照片氮量，以上是使用.NET 4.0的TPL實現的「隨火隨忘」技術。

我想使上述更加靈活和健壯。例如，如果圖像處理失敗（它使用GDI，所以很可能）或S3關閉（發生這種情況），我或用戶不會知道它。

我在考慮託管WCF服務作爲Windows服務，它輪詢圖像的文件夾。

我的主要網站只是將圖像FTP到「觀看」文件夾，然後該服務將負責圖像處理和上傳。

用戶不需要立即通知該照片已完成。換句話說，現在我們顯示「您的圖片正在處理中，並且很快就可以使用」消息。

綜上所述，該服務需要：

1. 調整圖像
2. 將圖像上傳到S3
3. 讀/寫數據庫
4. 能力 「重試」 失敗的圖像

有什麼建議嗎？是FileSystemWatcher一個不錯的選擇？

Answer 1

在我當前的項目中，我們實現了一個類似的中間件服務，負責使用FileSystemWatcher進行數據處理，並取得了相對的成功。有些事情要記住：

1. 一定要實施某種排隊核心處理。同時啓動100個圖像轉換過程並不是一個好主意。考慮使用ThreadPool。
2. FileSystemWatcher會在創建文件時立即發出通知，此時它可能仍然是隻寫鎖定 - 您將不得不執行定期檢查以確定開始處理的正確時刻。可能使用主循環和隊列。
3. 跟蹤細粒度狀態更改（如file_created，file_processing，file_processed，file_uploading等）。您可能確實需要它們進行調試。

希望這會有所幫助，祝你好運。