我們正在開發文件處理系統，其中多個文件處理應用程序從隊列中選取文件，執行處理並將文件放回隊列作爲響應。現在我們使用Windows文件系統（在網絡上共享一個文件夾）作爲隊列。我們共享一個文件夾並在其中放入文件，文件處理服務器應用程序從中拾取文件並在處理後放回。使用SQL Server進行文件隊列存儲
我們正在考慮將整個隊列引擎系統從Windows文件系統移動到SQL Server。將文件存儲到SQL Server並將SQL Server用作文件隊列後端是個好主意嗎？這些文件的大小約爲1-20mb，我們的系統每天處理大約10 000個文件。
你可以這樣做，但我更喜歡隊列 - 遠程實例或內存中的對象。我更喜歡真正的隊列，因爲我可以將聽衆集中起來，讓隊列將請求交給他們並管理他們的生命週期。如果將它們放入數據庫中，則必須編寫所有代碼。
每天10,000個文件意味着您需要每天24小時每8.64秒處理一個文件。 1-20MB文件的典型處理時間是多少？
文件的處理應該是異步的。
如果您有50個偵聽器，每個偵聽器處理一個20MB文件，則您的總內存佔用量將爲1GB。
就速度而言，最糟糕的情況是處理時間爲15分鐘。那是每小時四次，每天96次。所以你至少需要104個處理器才能在一天內完成10,000個處理器。這是很多服務器。
您也沒有考慮網絡延遲。每個文件都有來回傳送時間。它有四個網絡跳轉：一個從客戶端到數據庫，另一個從數據庫到處理器，再返回。 20MB可能會引入很多延遲。
我建議你看看Netty。我敢打賭它可以幫助處理這個負載。
文件大小是相當討厭 - 除非你可以例如顯着壓縮文件，SQL中的存儲需求可能會超過您感受到的任何好處。
您可能會考慮的是一種混合解決方案，即在SQL中對每個傳入文件進行建模（fileName，timestamp，uploadedby，processedYN等），每次上載後在SQL中排隊文件記錄，然後使用SQL進行排隊/排序（然後你可以運行審計，報告等SQL外）
混合的缺點是，如果你的文件系統崩潰，你有SQL，但不是你的文件。
文件大小不大，文件將作爲隊列項臨時存儲在數據庫中，處理後將被刪除。我們系統的主要因素是SPEED。隊列將以多快的速度從客戶端接收/發送文件到文件處理應用程序並返回。 – Tomas
我們的文件處理應用程序託管在不同的服務器上，我們不能使用內存中的隊列。你知道任何好的/快速的遠程隊列系統嗎？ 文件處理需要約1-15分鐘的範圍。 – Tomas
你已經睡在SQL Server中 - 爲什麼不用MS MQ？或者ActiveMQ或RabbitMQ或OpenJMS（對不起，我是一個Java人）。 – duffymo