如果您有 20 篇关于 /消息/ 每个分页页面上都有 20 个，例如 /新闻/page2/ /新闻/第399页/ 如果您在第 1 页添加一篇额外的文章，理论上您需要为这 400 个页面更新缓存（在 Akamai 或其他任何地方）。
新闻网站有什么巧妙的方法可以避免这种情况吗？
我们考虑在最后添加最新文章。但这对于新闻网站来说有点奇怪。也许只缓存每个部分的前 10 页是一种选择？
【问题讨论】：
标签： caching pagination akamai
简而言之，您需要停止将页面视为一个整体，而将注意力集中在各个页面元素上。 HTML 可以使用相对较低的 TTL 进行缓存，而静态元素（如图像、JS、CSS 和字体）可以使用较高的 TTL 进行缓存。这让您不必担心清除缓存，让 CDN 为您处理负载。
Akamai 客户社区有一个很棒的blog post that looks at managing caches with frequently updated websites。关键是要在 TTL 和更新内容的频率以及支持 IMS 请求和“HTTP/1.1 304 Not Modified”响应之间找到适当的平衡。
来自博文：
对于 rapid[ly] update[d] 内容，我们需要平衡缓存和更新时间。这是我推荐的一个很好的公式；
- HTML 缓存：不是为每个最终用户请求重新验证来源，或者使用一两分钟的固定低 TTL - 想象一下绝大多数用户可以每 60 秒接收一次更新，有时只有一小部分用户最多可以看到 2 分钟前的内容 - 但向源发出的内容刷新请求数量显着减少。
- 图像、字体、图标可以缓存很长时间，因为它们很少更改。在这些项目确实发生变化的罕见情况下，可以使用新文件名来确保快速获取新图像，或者可以使用 Akamais CCU/CCU API 来强制刷新内容。 7 天或 30 天的 TTL 在这里很常见 - 尽管我已经看到网站缓存了几个月（或更长时间！）用于非常流行、非常静态的内容。
- 需要启用源以支持“If-Modified-Since”HTTP GET 和 HTTP 304 响应。
（1）中指定的时间可以向上或向下调整，但通常我发现对于广大用户来说，HTML 内容上的 60 或 120 秒 TTL 往往是一个最佳点，尽管有些客户喜欢 3 到5分钟范围。如果您发现您的业务更新需求不那么频繁，则该数字可能在更高的范围内。该数字也可以更小，但请记住，我们正在努力降低源请求 - 更少的数字意味着从 Akamai 到 Origin 的刷新频率更高。
...
如果我告诉您，这个 CMS 驱动的网站会确保几乎所有用户的 HTML、JS 和 CSS 内容每 3.5 分钟从源站刷新一次 - 但在任何时候，源站每秒从 Akamai 获得的点击次数都不会超过 28 次或使用超过 3mbps 的带宽？
【讨论】：