高性能被动访问优化的动态 REST 网页

Question

以下问题是关于为下文所述的 REST 启发行为实现或已经存在的缓存框架。

目标是 GET 和 HEAD 请求的处理效率应与对静态页面的请求一样有效。

在技术方面，我认为Java Servlets 和MySQL 来实现站点。 （但好的理由的出现可能仍然会影响我对技术的选择。）

网页应支持 GET、HEAD 和 POST； GET 和 HEAD 比 POST 更频繁。页面内容不会随着 GET/HEAD 改变，只有 POST 改变。因此，我想直接从文件系统处理 GET 和 HEAD 请求，而只处理来自 servlet 的 POST 请求。

1. 第一个（有点不完整）的想法是 POST 请求会为连续的 GET/HEAD 请求预先计算 HTML 并将其存储到文件系统中。然后 GET/HEAD 将始终从那里获取文件。我相信这可以通过条件 URL 重写在 Apache 中轻松实现。
2. 更精细的方法是，如果存在预先计算的文件，GET 将从文件系统中提供 HTML（HEAD 也使用它），否则将调用 servlet 机器动态生成它。在这种情况下，POST 不会生成任何 HTML，而只会适当地更新数据库并从文件系统中删除 HTML 文件作为标志，以便使用下一个 GET/HEAD 重新生成它。第二种方法的优点是它可以更优雅地处理网页的“初始阶段”，此时尚未调用 POST。我相信这种惰性生成和存储方法可以通过提供一个错误处理程序在 Apache 中实现，该处理程序将在“文件未找到但应该存在”的情况下调用 servlet。李>

在稍后的改进中，为了节省带宽，缓存的 HTML 文件也应该以 gzip 版本提供，当客户端理解时提供。我认为基本机制应该和未压缩的 HTML 文件相同。

由于会有很多类似 REST 的页面，因此这两种方法可能偶尔都需要一些机制来垃圾收集很少使用的 HTML 文件以节省文件空间。

总而言之，我相信我的 GET/HEAD 优化架构可以干净利落地实现。首先，我想对这个想法提出意见（我认为它很好，但我可能错了）以及是否有人已经使用过这种架构，甚至可能知道实现它的免费框架。

最后，我想指出客户端缓存不是我所追求的解决方案，因为多个不同的客户端会 GET 或 HEAD 同一个页面。此外，如果预先计算的文件存在，我想在 GET/HEAD 请求期间绝对避免使用 servlet 机制。甚至不应调用它来在 GET/HEAD 请求中提供与缓存相关的 HTTP 标头，也不应将文件转储到输出。

问题是：

1. 是否有更好的（标准）机制来实现开头所述的目标？
2. 如果没有，是否有人知道像我考虑的那样的现有框架？

我认为 HTTP 缓存没有达到我的目标。据我了解，HTTP 缓存仍需要使用 HEAD 请求调用 servlet，以了解 POST 是否同时更改了页面。由于页面更改将在不可预知的时间点发生，因此说明过期时间的 HTTP 标头还不够好。

Answer 1

使用 Expires HTTP 标头和/或 HTTP 条件请求。

过期

Expires 实体标头字段给出了响应被视为陈旧的日期/时间。缓存（代理缓存或用户代理缓存）通常不会返回陈旧的缓存条目，除非它首先通过原始服务器（或具有实体的新副本的中间缓存）进行验证。有关过期模型的进一步讨论，请参见第 13.2 节。

http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html

条件请求

使用 Expires、Last-Modified 和/或 ETag 标头装饰可缓存响应。使用 If-Modified-Since、If-None-Match 标头、If-* 等使请求有条件（参见 RFC）。

例如 上次响应标头：

 ...
 Expires: Wed, 15 Nov 1995 04:58:08 GMT
 ...

不要在过期日期（Expires 标头）之前对资源执行新请求，然后执行条件请求：

...
If-Modified-Since: Wed, 15 Nov 1995 04:58:08 GMT
...

如果资源未被修改，则返回 304 Not Modified 响应代码并且响应没有正文。 200 OK，否则返回带有正文的响应。

注意：HTTP RFC 还定义了 Cache-Control 标头

请参阅 HTTP 中的缓存 http://www.w3.org/Protocols/rfc2616/rfc2616-sec13.html