用于提供“陈旧”内容的CDN支持/配置,在后台刷新

问题描述 投票:0回答:1

目标

不管陈旧如何,总是从CDN EDGE缓存提供内容。尽可能在后台刷新它。

问题

我有一个NextJS应用,可在服务器端渲染一些React组件并将其交付给客户端。对于此讨论,我们只考虑我的主页,该主页未经身份验证,并且每个人都相同。

我想要的是服务器呈现的主页要缓存在CDN的EDGE节点上,并尽可能经常或始终从该缓存中提供给最终客户端。

根据我的阅读,CDN(如Fastly)可以正确支持与缓存相关的标头设置(如Surrogate-ControlSurrogate-Control),但实际上,我看不到它的运行方式。 d期望。我看到的是:

  • 请求错过高速缓存,并在先前的请求将其预热后返回原点
  • 请求是从缓存中提供的,但是在源发布新内容时永远不会更新

示例

请考虑以下时间轴:


[[T0]-Visitor1请求Cache-Control: stale-while-revalidate-CDN缓存完全冷,因此该请求必须回到我的来源(AWS Lambda)并重新计算主页。返回带有标头www.mysite.comSurrogate-Control: max-age=100的响应。然后,将访问者1送达首页,但他们不得不等待5秒钟! YUCK!也许没有其他访客有同样的命运。

[[T50]-Visitor2请求Cache-Control: public, no-store, must-revalidate-CDN缓存包含我的文档,并将其立即返回给访问者。他们只需要等待40毫秒!太棒了在后台,CDN从我的来源重新获取主页的最新版本。原来它没有改变。

[[T80]-www.mysite.com将新内容发布到主页,使所有缓存的内容真正过时。该网站的第2版现已上线!

[[T110]-访客1返回到www.mysite.com-从CDN的角度来看,自访客2发出请求以来只有60秒钟,这意味着由访客2启动的后台刷新应该导致首页的<100 s旧版本在缓存中(尽管首页的V1,而不是V2)。从缓存向Visitor1提供60年代陈旧的V1主页。这次为Visitor1提供了更好的体验!该请求将启动CDN缓存中陈旧内容的后台刷新,并且这次起源返回该网站的V2(已于30年前发布)。

[[T160]-访问者3访问www.mysite.com-尽管是新访问者,但CDN缓存现在是从访问者1的最近一次后台刷新触发中刷新的。向Visitor3提供了一个缓存的V2主页。

...

只要每100秒钟至少有1位访问者访问我的站点(因为www.mysite.com,就不会有访问者经历到我原籍的完整往返的等待时间。


问题

1。这是对现代CDN的合理要求吗?我无法想象这比总是返回到原点(没有CDN缓存)还要费力,但是我一直在努力从任何CDN提供程序中找到有关正确方法的文档。我现在正在使用Fastly,但也愿意尝试其他任何方法(我先尝试过Cloudflare,但请阅读它们不支持max-age=100

2。正确的标题是什么? (假设CDN提供程序支持它们)我在Fastly和Cloudflare中同时使用了stale-while-revalidateSurrogate-Control: maxage=<X>,但似乎没有正确执行此操作(请求在最大时间范围内不会在原点上发生变化,直到发生缓存未命中)。

3。如果不支持此功能,是否有API调用可以让我将内容更新推送到CDN的缓存层,有效地说:“嘿,我刚刚为此缓存密钥发布了新内容。 !“

我可以使用Cloudflare工作者使用自己的KV存储来实现这种缓存,但是我认为在实现似乎很常见的问题的代码解决方案之前,我需要做更多的研究。

提前感谢!

目标始终从CDN EDGE缓存提供内容,无论其状态如何。尽可能在后台刷新它。问题我有一个NextJS应用程序,它在服务器端渲染了一些React组件,并且...

cdn next.js cloudflare cache-control fastly
1个回答
0
投票

关于问题3。您可以为进行更改的每个文件使用新名称防止不必要的缓存或按照您的建议使用API​​ cloudFlare释放缓存。有可能,您可以在此处找到更多信息Surrogate-Control: maxage=<X>

© www.soinside.com 2019 - 2024. All rights reserved.