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

Question

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

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

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

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

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

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

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

其次，这是在网络农场场景中..因此需要考虑安装/部署/维护。

很想看看其他人的想法。

Answer 1

我喜欢你的解决方案。

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

使用这种架构，您可以拥有多个编码服务器，如果这是瓶颈所在。

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

Answer 2

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

它也使您的 Web 应用程序无法处理。