图像处理架构设计建议

Question

我正在开发一个标准的 ASP.NET MVC 3 Web 应用程序（托管在 IIS 7 上）。该网站允许用户上传照片等。

上传过程如下：

1. 用户使用小部件（当前为 plupload）从他们的 PC 中选择文件。
2. AJAX 调用发生在我的服务器上，图像在 HTTP POST (Request.Files) 中
3. 服务器调整照片大小 N 次
4. 每张调整大小的照片都会上传到 Amazon S3

目前，上述内容是通过使用 .NET 4.0 的 TPL 的“即发即弃”技术实现的。

我想让上述内容更加灵活和健壮。例如，如果图像处理失败（它正在使用 GDI，所以很可能），或者 S3 已关闭（发生这种情况），我或用户不会知道。

我正在考虑将 WCF 服务托管为 Windows 服务，它会轮询文件夹中的图像。

我的主网站只需将图像 FTP 到“观看”文件夹，然后该服务将负责图像处理和上传。

不需要“立即”通知用户照片已完成。换句话说，现在我们显示“您的图像正在处理中，很快就会可用”消息。

综上所述，服务需要：

1. 调整图片大小
2. 将图像上传到 S3
3. 读/写数据库
4. 能够“重试”失败的图像

有什么建议吗？ FileSystemWatcher 是个不错的选择吗？

Answer 1

在我当前的项目中，我们实现了一个类似的中间件服务，负责使用 FileSystemWatcher 进行数据处理，并取得了相对成功。需要记住的一些事情：

1. 确保为核心处理实施某种排队。同时启动 100 个图像转换进程并不是一个好主意。考虑使用线程池。
2. FileSystemWatcher 将在文件创建后立即发出通知，此时它可能仍处于只写锁定状态 - 您必须执行定期检查以确定开始处理的正确时间。可能使用主循环和队列。
3. 跟踪细粒度状态更改（如 file_created、file_processing、file_processed、file_uploading 等）。您可能真的需要它们进行调试。

希望这会有所帮助，祝你好运。