C# 在Azure上调整/缓存JPEG图像的大小

我有一个用.NET4.5/MVC4编写的网站，该网站允许用户上传图像等。这些图像可以以各种尺寸显示在整个站点中。目前，其工作方式如下：

• 图像将上载并在内存中重新调整大小，最大宽度为640px（站点将显示的最大宽度）
• 调整大小的映像保存到磁盘的/assets/photos/source/{id}-{timestamphash}.jpg
• 当对不同大小的图像的请求通过时，我通过组合{id}-{hash}来获得文件名，{hash}是id、高度、宽度和我获得图像所需的一些其他信息的组合的散列
• 如果该图像存在于/assets/photos/cache中，我只需返回它，否则我将使用源图像在内存中创建它，然后将其保存到缓存目录

我喜欢这种方法，因为它发生得很快，而且都发生在内存中或通过磁盘检索

我希望最终将我的站点移动到Azure。如果我的所有图像都存储为blob，那么在Azure中这样的工作流将如何发生？使用这样的重新调整大小/缓存策略是否仍然有效，或者是否有其他替代方案？当映像从服务器上载到Azure时，您不会招致网络延迟吗？今天，它只是被保存到磁盘，这显然要快得多

---

只是想了解一下如何将这样的工作流迁移到Azure上可行且可扩展的工作流程。

鉴于您的上述评论，为什么不创建一个后台任务，在上传时将其大小调整到所有可接受的大小，并将每个任务存储到Azure blob存储中。如果您根据请求调整大小，您会遇到一些延迟和延迟，因为您需要下载源映像，调整大小，然后上载到blob存储，然后将用户重定向到blob存储url。考虑到blob存储的“廉价性”，我认为多花几毛钱购买额外存储将超过上述场景的潜在缓慢性

伪代码如下：

[HttpPost]
public ActionResult FileUpload(HttpPostedBaseFile file){
   if(ValidateFile(file)){
      //fire off a background tasks that resizes and stores each file size to the azure
      //blog storage.  You could use a naming scheme such as id_size.imageTypeExtension
   } 
}

现在，当请求一个文件时，您仍然可以使用相同的例程，但是不返回文件结果，而是返回重定向结果

public ActionResult GetImage(string hash){
    //do stuff to get image details
    return Redirect("http://yourAzureBlobStorageDomain.com/Assets/Images/Cache/" + imageDetails")
}

这很酷，因为您不需要将映像下载到web服务器并提供服务，只需将请求直接重定向到blob存储！这将影响图像标记，如下图所示

将命中您的web应用程序，强制重定向到blob存储中的实际映像位置

您不希望在Azure web角色上永久存储任何内容是正确的，因为web角色可以随时移动，从而丢失任何本地存储的数据

这只是一种简单的方法，可以使您的代码保持现在的基本状态，只需进行最小的更改。您可以对其进行修改，使其行为更像您现在拥有的，因为您可以查询blob存储，如果图像存在，如果存在，则重定向，如果不存在，则生成、存储和重定向，但我相信您会发现，鉴于您需要下载源图像，此时您会遇到更多延迟问题，完成你的工作，然后重新加载图像，然后再指示用户的浏览器在哪里找到它

---

但是，这将由您决定是否值得花额外的时间按需调整大小，而不是存储每个图像的多个大小。作为补充说明，我们没有注意到从web/worker角色使用blob存储时存在显著的延迟问题。显然，它比从磁盘中检索要高，但它并没有带来我们所能看到的显著增长。

您事先知道可以请求的不同大小吗？是的，我有一个可接受大小的列表，以防止有人向我的资产服务器发送无限大小组合的请求并填充硬盘。实际上，这是一种有效的方法私人的斑点也一样。您只需要在URI中附加一个共享访问签名。@DavidMakogon-哦，知道这个很酷！我会把这句话从我的答案中删去。我唯一关心的是，上传和其他尺码之间有一定的滞后时间。当前，用户上传图像，并立即重定向到一个视图，该视图向用户显示较小尺寸的图像之一。我将把这个标记为答案，因为这是一个彻底的答案，为我指明了正确的方向。如果您对如何立即提供较小的大小有任何想法，我很想听听。@Scott-我最初的想法是，您可以直接从控制器/操作返回较小的大小作为文件结果，或者…这将是使用本地存储（临时、短期文件）的好时机以帮助解决当前的限制。但是，您需要在这方面添加一些逻辑，以确保以后的其他请求被重定向到正确的位置（用户页面刷新等）