這是一個很好的處理/操作文件上傳的架構/設計概念嗎？

Question

我正在尋找添加多文件上傳到我們的ASP.NET MVC網絡應用程序。我將使用3rd Party Multi-File uploader Aurigma來處理實際上傳。

一旦每個文件是由web服務器接收到的100％時，它需要被檢查以下

1. 是圖像或視頻。
2. 如果它是一個圖像，是否需要調整大小？如果是的話，調整大小。
3. 如果它是一個視頻，我們需要重新編碼爲閃光燈（不幸的是..帶來HTML5 :)）
4. 最後，存儲在S3亞馬遜。

所以我知道如何做大部分步驟1到4 - 這不是問題。

我的問題是：我應該怎麼處理這個工作流程？特別是如果我一次得到大量的媒體 - >畢竟，這是一個多文件上傳:)我不想有很多媒體一次處理（例如，5視頻的編碼閃存。 ）。

所以我想我可能有MSMQ安裝，當每個文件獲得100％接收，然後彈出到MSMQ。這樣，一次只有一件物品得到處理。這樣做的代價是，如果處理中有很多昂貴的處理，隊列可能實際上開始在那裏獲得幾件物品......並且從物品上傳到站點時會有一些等待期，直到它實際上100％被處理。我們可以在UI中輕鬆處理這些信息，告訴他們尚未完成。

所以 - 這聽起來像一個好方法來處理這個問題？

其次，這是在一個網站的場景..所以安裝/部署/維護需要考慮。

很想看看其他人在想什麼。

Answer 1

如何運行一個監視臨時目錄（文件上傳目錄）的Windows服務。然後讓它產生同時處理的X個線程。這樣，如果將X設置爲10，那麼它一次只能處理10個文件。一旦處理完畢，它們就可以移動到永久目錄，服務將接收臨時目錄中的下一個文件。

它也使處理不在您的Web應用程序中。

Answer 2

我喜歡你的解決方案。

MVC層應負責驗證文件並僅對請求進行排隊。後臺進程應該執行編碼和其他繁重工作。

通過這種架構，您可以獲得多個編碼服務器的能力，如果這是瓶頸最終發生的地方。

我以前在類似的情況下使用MSMQ。這是一個偉大的「火災和遺忘」解決方案，特別是跨服務器邊界。顯然你可以使用Web服務，共享文件系統等。爲UI - >後臺處理通信，但我認爲MSMQ是正確的答案。