保存多个大小的图像

Question

我们的网站上有很多用户生成的图片。当用户上传他们的图片时，我们只存储原始图片。但是，根据页面的不同，我们显示这些图像的不同大小(小、中、大、原始)。是否有必要存储这些图像的所有大小，还是有更好的方法？目前，我们正在使用CSS调整它们的大小，但这确实很慢。

Answer 1

以所需的大小存储图像的多个副本可能是最好的选择，原因如下：

1. 磁盘空间相对便宜，
2. 正如@Jalayn所评论的，缩小大小的图像不需要太多的处理能力，
3. 正如@评论的那样，在可能的情况下提供较小的图像将节省带宽成本。

上传一个文件后，启动一个异步进程来生成各种副本，这样用户就不必等待了。

Answer 2

有很多方法你可以处理这件事，我认为“正确的方式”取决于。

然而，我认为我们都同意，储存不同的大小是最好的方式。

您的站点的设置方式可能不适合您(例如，小、中、大)，当然，存储所有可能的组合也是不切实际的。因此，说到这里，我会根据您提供的最常见的尺寸来存储几个不同的尺寸。

如果你大部分时间都在存储一个100 pxx100px图像，并且需要一个90 pxx90px图像，那么只需为100x100提供服务，并使用css将其缩小，这并不像必须处理900x900px图像并将其缩小。这是个很好的妥协。

Answer 3

我不同意文件存储，如果可能的话，这些临时图像不应该存储，因为它们总是会造成混乱。

磁盘空间非常便宜，但是从磁盘上提供文件的速度很慢，而且SSDs -速度很快--还没有那么便宜。这个“生成我们能想到的所有图像大小”模型不是未来的证明，它的工作，直到你可以预定义所有的图像分辨率，你需要显示。总有剩余内容的问题，这是一个痛苦的维护，但至少它是同样的问题总是。业务规范可以很容易地破坏这个模型。如果需要图像的新分辨率，则必须编写调整大小的脚本，遍历整个现有的映像库并创建新的分辨率，以便旧图像能够在新的设计中工作。这是可行的，但它需要系统管理员。但是，如果业务规范要求您具有很强的响应能力，并且总是更改无法预定义的图像大小，则该模型就会失败。

我们曾经这样做过，现在我们使用清漆缓存和调整大小的应用程序组合来提供任意大小的图像，而不显式地将它们存储在磁盘上。由于图像是从缓存服务的，它们的传送速度非常快。有了这个解决办法，就没有必要：

• 创建每个图像版本，特别是当您不知道要创建什么时
• 删除剩余图像
• 运行异步进程来调整映像的大小
• 重新调整旧图像到新分辨率的大小
• 由于文件系统限制，创建不同名称的文件。

在我们的模型中，当访问者请求调整大小的图像时，调整大小会发生在请求响应过程中。换句话说，将调整大小的图像加载到浏览器中的访问者--从未显示过的图像--将不得不等待一些额外的时间，而系统将创建新的、调整大小的图像。

额外功能:通过调用一个简单的URL，一切都是可测试的，不需要运行图像调整程序来创建不同版本的图像。该图像将在飞行中创建。

• 原始图像：http://myserver.com/imagename.jpg
• 调整大小的图像：http://myserver.com/imagename.jpg?w=317 (创建317像素宽的图像)

对http://myserver.com的每一个请求都将到达处理这些传入请求的Varnish。清漆被配置为当它获得一个没有查询参数的请求时，可以在不缓存内容的情况下服务静态文件系统中的请求。在这种情况下，关闭缓存是一个好主意，只有当原始图像永远不会显示给访问者，只有调整大小的(可能是因为原来的是相当大的)。

如果传入的请求具有查询参数，Varnish将该请求分派给调整大小的应用程序。应用程序通过在不使用查询字符串的情况下重新运行原始请求来获得基本映像，这意味着Varnish将向应用程序提供原始图像。作为一个负载均衡器，它甚至可以减轻问题，如应用程序超时。

然后，应用程序进行适当的调整(检查参数有效性、规则等)，并使用调整大小的图像做出响应。响应返回到响应链中，这是Varnish，它缓存调整大小的图像，并将其服务于客户端。

对相同大小图像的任何后续请求(又名:具有相同查询参数的相同URL )都将从缓存中处理，直到缓存过期为止。

通过这种方式，清漆被用作存储设备，并增加了作为缓存的额外好处。