从Azure Blob存储服务懒散的缩略图-存在的开销是什么？

Question

我有一个网站，用户上传图片。这些图片显示在网站的不同部分与不同的缩略图尺寸。由于该网站仍在快速开发，我还不想承诺一定数量的拇指大小。因此，我认为我应该懒洋洋地制作缩略图。

在这两种选择中，哪种是最有表现力的方法：

1. 当我使用缩略图时，将维度转换为一个规范的文件名(比如“bighouse-拇指-160x120”)。使用client.GetContainerReference(containerName).GetBlockBlobReference(key).Exists()；检查该文件是否存在于blob存储中，如果它不存在，则生成它并保存它。
2. 当我使用缩略图时，查询我的SQL数据库以查看缩略图是否存在。如果存在blob，则从DB获取blob，并将其作为HTML发出。如果不存在，则生成它并更新SQL数据库。

我以前使用过#2，但从设计上讲，它是复制状态，这是不好的。如果查询天蓝色是否存在blobs是可伸缩的，我宁愿这样做。我不太理解Asp.Net中的线程模型。如果我有200个用户请求拇指，我的天蓝色存在的调用会同时发生吗？即使他们这样做了，两次往返似乎是很大的开销。我假设往返数据库更快，并且更容易使用一般的缓存解决方案。

正确的答案是什么？

Answer 1

不管开销如何，当您上传/存储图像时，我都会预先生成缩略图。通过这种方式，您可以将生成缩略图的负担从多次执行(检索图像)转移到执行次数要少得多的缩略图(存储图像)。

考虑以下情况，当您懒洋洋地在第一个视图上生成缩略图时：

• 检查现有缩略图(是false，记住第一个视图；)
• 生成缩略图
• 储存缩略图
• 将缩略图发送到客户端

使用预生成的缩略图，这个过程要短得多：

• 将缩略图发送到客户端

好了。

使用“延迟生成”，检查现有的可能是昂贵的，因为网络开销(对每一个命中！)，生成缩略图可能是非常昂贵的内存-&CPU方面，比你必须存储它，与网络开销再次。您甚至可以将生成缩略图的工作卸载到单独的进程(可能是由队列消息启动的)，以承担生成图像的负担，使其更远离您的away服务器。

然而，这就引出了当您引入一个新的缩略图/图像大小时应该做什么的问题。当您预先生成缩略图时，您可以编写一个简单的工具来创建新的大小并存储它们，如果您选择了单独的进程路线，它甚至会更简单。只需升级单独的进程，为每个现有映像生成一个队列消息，并让它完成它的工作。