这是处理/操作文件上传的良好架构/设计概念吗？

Question

我正在考虑将多文件上传添加到我们的ASP.NET MVC网络应用程序中。我将使用3rd Party Multi-File uploader Aurigma来处理实际的上传。

一旦Web服务器100％收到每个文件，就需要检查以下内容

1. 是图像还是视频。
2. 如果是图像，是否需要调整大小？如果是这样，请调整大小。
3. 如果是视频，我们需要将其重新编码为flash（不幸的是......带上html5 :)）
4. 最后，存放在S3亚马逊上。

所以我知道如何做大部分步骤1到4 - 这不是问题。

我的问题是：我应该如何处理这个工作流程？特别是如果我一次获得大量媒体 - ＆gt;毕竟，这是一个多文件上传器:)我不希望一次处理大量媒体（例如，5个视频被编码为闪存......）。

所以我想我可能已安装MSMQ，当每个文件100％收到时，然后将其弹出到MSMQ。这样，只有一个项目一次处理。这样做的代价是，如果有很多昂贵的处理，那么队列实际上可能会开始在那里获得一些项目...并且从项目开始时将有一些等待期。上传到网站，直到它实际上100％处理。我们可以在UI中轻松处理这个问题，告诉他们还没有完成。

那么 - 这听起来像处理这个问题的好方法吗？

其次，这是在Web场方案中..因此需要考虑安装/部署/维护。

很想看到别人在想什么。

Answer 1

我喜欢你的解决方案。

MVC层应负责验证文件并仅对请求进行排队。后台进程应该进行编码和其他繁重的工作。

使用这种架构，您可以拥有多个编码服务器，如果这是瓶颈结束的地方。

过去我在类似的情况下使用过MSMQ。这是一个伟大的“即发即忘”解决方案，尤其是跨服务器边界。显然，您可以为UI使用Web服务，共享文件系统等 - ＆gt;后台处理通信，但我认为MSMQ是正确的答案。

Answer 2

运行一个监视临时目录的Windows服务（文件上传的目录）怎么样？然后让它产生同时处理的X线程。这样，如果将X设置为10，那么它一次只能处理10个文件。处理完毕后，可以将它们移动到永久目录，服务将获取临时目录中的下一个文件。

它也使处理过程远离您的Web应用程序。