架构:处理大规模照片上传和调整大小

时间:2014-04-22 15:02:18

标签: c# image-processing azure file-upload azure-storage-blobs

我有一个系统,用户可以上传大约16百万像素的全分辨率图像,从而产生大文件。

目前的方法是:

  1. 通过HTTP请求接收上传。
  2. 在请求中,将原始文件写入blob store
  3. 仍然在请求中,以各种分辨率制作大约10份文件。 (这些是不同尺寸的缩略图,一些用于Hi-DPI(视网膜)设备,还有一个用于全尺寸观看的尺寸。我还将图像转换为WebP。
  4. 然后,我将所有结果转移到不同地区的blob商店,用于私人CDN目的。
  5. 显然,问题在于,由于这一切都是在HTTP请求中完成的,因此与其他任何典型的HTTP请求相比,它消耗的服务器资源要多得多,尤其是当用户开始批量上传图像时,一次几个用户。如果用户上传大图像,则内存消耗会急剧增加(我使用ImageMagick.NET进行图像处理)。

    这种架构是否更合适:

    1. 接收文件上传,写入blob,向处理队列添加通知,将成功返回给用户。
    2. 单独的工作服务器接收新文件的通知,并开始所有重新调整大小,处理和复制。
    3. 我只是将客户端JavaScript设置为不加载图像预览几秒钟,或者如果找不到图像则重试它(意味着图像仍在处理中,但很可能很快就会显示出来) )。
    4. 至少这种新方法将更容易扩展,具有更可预测的性能。但是,像照片上传一样处理“每一天”的事情似乎需要做很多工作。 有更好的方法吗?

      我知道新方法遵循与使用外部重新调整大小服务相同的原则,但由于我担心某些第三方服务的隐私,因此不要在内部执行此操作。这仍然意味着我必须调整客户端来处理丢失/未处理的图像。

2 个答案:

答案 0 :(得分:2)

是的,你所描述的是一种更好的方式。这听起来更复杂,但大多数可扩展站点处理大负载的方式是将其卸载到队列中并让工作人员处理它。

我在步骤2中为您的案例添加更正:

一个单独的工作服务器监视一个队列,并在出现指示它的消息时启动所有重新调整大小,处理和复制。

答案 1 :(得分:1)

另一种选择是使用新的Web作业功能。实际上,您的场景似乎非常常见(在图像处理方面),它被列为Typical Scenario on MSDN之一。

  

图像处理或其他CPU密集型工作。网络的一个共同特征   网站是上传图片或视频的能力。通常你想   在上传内容后操纵内容,但您不想制作内容   用户等你这样做。

无论是否更好,我都会由你决定。