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

Question

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

上传过程如下：

1. 用户利用插件（目前plupload）从他们的PC选择文件。
2. AJAX调用发生到我的服务器，在HTTP POST图像（Request.Files）
3. 服务器重新调整
4. 每个大小的照片被上传到亚马逊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等）。您可能确实需要它们进行调试。

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