我有一个用户上传图像的网站。这些图像以不同的缩略图尺寸显示在网站的各个部分。由于该网站仍处于快速开发阶段，因此我还不想 promise 一定数量的拇指尺寸。因此我相信我应该懒惰地生成缩略图。
在这两个选项中，这是执行此操作的最有效的方法:
当我提供缩略图时，将尺寸转换为规范的文件名(例如“bighouse-thumb-160x120”)。使用 client.GetContainerReference(containerName).GetBlockBlobReference(key).Exists() 检查文件是否存在于 Blob 存储中；如果不存在，则生成并保存。
当我去提供缩略图时，查询我的 SQL 数据库以查看缩略图是否存在。如果存在，则从数据库获取 blob URI 并将其作为 HTML 发出。如果不存在，则生成并更新SQL数据库。
我过去使用过#2，但从设计角度来说，它是重复的状态，这很糟糕。如果查询 azure 是否存在 blob 是可扩展的，我宁愿这样做。我不太了解Asp.Net中的线程模型。如果我有 200 个用户请求点赞，我的 azure Exists 调用是否会全部并行发生？即使他们这样做，两次往返似乎也会产生很大的开销。我认为数据库往返速度更快，并且更容易实现通用缓存解决方案。
正确答案是什么？
最佳答案
无论开销如何，我都会在您上传/存储图像时预先生成缩略图。通过这种方式，您可以将生成缩略图的负担从多次执行的操作(检索图像)转移到很少执行的操作(存储图像)。
当您在第一个 View 上延迟生成缩略图时，请考虑以下场景:
- 检查现有缩略图(为
false，第一次查看请记住；)) - 生成缩略图
- 存储缩略图
- 将缩略图发送给客户端
使用预先生成的缩略图，过程要短得多:
- 将缩略图发送给客户端
完成。
使用“延迟生成”时，由于网络开销(每次点击!)，对现有的检查可能会很昂贵，生成缩略图可能会在内存和 CPU 方面非常昂贵，并且比您必须存储它还要昂贵，并且有网络开销再次。您甚至可以将生成缩略图的任务转移到一个单独的进程(可能由队列消息启动)，以进一步远离网络服务器生成图像的负担。
但是，这提出了当您引入新的缩略图/图像尺寸时应该做什么的问题。当您预先生成缩略图时，您可以编写一个简单的工具来创建新尺寸并存储它们，如果您采用单独的流程路线，那就更简单了。只需升级单独的进程，为每个现有图像生成一条队列消息，然后让它完成其工作。
关于asp.net - 从 Azure Blob 存储提供惰性缩略图图像 - Exists 的开销是多少？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/29783177/