【问题标题】：Custom Image Handler: Caching Strategy自定义图像处理程序：缓存策略
【发布时间】：2010-10-08 08:37:18
【问题描述】：

情景

我正在为通信应用程序构建自定义 CMS。用户可以将图像上传到服务器，然后在他们使用 markdown 编写的帖子中引用它们。图像存储在数据库中，并使用 images/{id} 形式的 url 引用。自定义图像处理程序检索这些并设置远期过期标头，因此不会一遍又一遍地获取它们。将图像存储在文件系统中不是每个客户的选择。

为了提高性能，帖子以降价和 html 形式存储在数据库中。

降价

###Header
Lorem Ipsum dolor sit amet.  ![funny cat](images/25)

HTML

<h3>Header</h3>
<p>
  Lorem Ipsum dolor sit amet. <img alt="funny cat" src="images/25" />
</p>

问题

这些图像也是可编辑的。从缓存的角度来看，这提出了一个问题。编辑图像时，我需要确保浏览器获取最新版本。我提出了以下解决方案，但我发现所有这些解决方案都缺乏。

可能的解决方案

版本字段

将版本字段与图像一起存储。当图像被编辑产生images/{id}/version/{version}形式的url时增加它。

如果图像 url 总是从数据库中生成，那就太好了。但是，我将 url 作为文本存储在帖子中，并且必须为这些请求预处理可能的大量文本。此外，链接图像会很麻烦，因为在编辑图像后 url 会变得陈旧。这可能不是一个好主意。

新网址

当图像被编辑时，将其作为新条目存储在数据库中。

这意味着没有版本维护，但旧链接和旧帖子会遇到同样的问题。他们永远不会更新。性能会很好，但问题仍然存在。

304 - 未修改

为每个图像存储一个最后编辑的字段。当有条件请求时返回 http 状态 304 - 未修改，减少带宽使用。

这似乎是迄今为止我得到的最佳解决方案。除非经过编辑，否则图像会被缓存，但我以前从未使用过这种方法。如果页面上有 50 张图像，则仍有 50 个请求向服务器发送。带宽将减少，但延迟仍然存在。这种方法值这个成本吗？

问题

我在这方面的经验很少，我希望你们所有人都有更多经验。上述任何解决方案是否可行？如果是这样，您对他们的体验如何？如果不是，有什么更好的方法？

【问题讨论】：

标签： html http caching httphandler

【解决方案1】：

正如您所说，Conditional GET 是最好的选择，因为您只需要检查一个请求标头（If-None-Match 或 If-Modified-Since）并返回相应的状态码（200 或 304 ) 和一个标题（E-Tag 或 Last-Modified）。然后浏览器会处理图片缓存。

此外，根据您的服务器框架，如果您将图像存储在数据库中，您可以在第一次需要它们时缓存它们（在有限的时间内，因此您不会消耗所有服务器内存）。当您需要重复读取相同的图像时，这会有所帮助，从而节省数据库查询。当然，如果你编辑它们，你需要从服务器缓存中删除你的图像。

编辑：感谢您接受答案。如果您需要，这里有一个很好的解释性链接：HTTP Conditional Get for RSS Hackers。

【讨论】：

【解决方案2】：

将图像放在磁盘上，让您的网络服务器处理它。

文件可以保持相同的名称（以及因此的 URL），并且 Web 服务器可以处理来自浏览器的修改后的标头。浏览器也可以对带有已知扩展名的 URL 感到更满意。

将图像放入数据库并通过脚本提供它们通常不是一个好主意。只需引用数据库中的 URL。

【讨论】：

这绝对是一种选择，但会使扩展到多台服务器变得更加困难。