图像处理体系结构的设计建议

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个图像转换过程并不是一个好主意。考虑使用ThreadPool。
2. FileSystemWatcher将在文件创建后立即发出通知，此时它可能仍然是只写锁定的 - 您必须执行定期检查以确定开始处理的正确时刻。可能使用主循环和队列。
3. 跟踪细粒度状态更改（如file_created，file_processing，file_processed，file_uploading等）。您可能真的需要它们进行调试。

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