Question

我最近通过云功能和Firebase托管实现了SSR。

构建JS捆绑包时，它会收到一个缓存突发后缀（main.1.js）。

在函数内部，我有以下代码用于缓存Cloud Function的结果

res.set('Cache-Control', 'public, max-age=300, s-maxage=300');

在部署期间，我先部署托管，然后再部署云功能

firebase deploy --only hosting:production && gcloud functions deploy ssr --runtime nodejs8 --trigger-http --source dist/server

firebase托管部署将main.1.js替换为main.2.js。

由于缓存破裂，文件现在有所不同（main.2.js），但是由于云功能又缓存了5分钟-访问网站时出现错误（因为引用了main.1.js在该功能的缓存版本中不再可用。

您将如何解决此问题？我可以有两个活动的部署并一个接一个地激活吗？

Answer 1

缓存控制标头public, max-age=300, s-maxage=300告诉处理请求的任何一方（主要是用户的浏览器和Google的CDN服务器，但也可以是用户使用的代理）如何缓存请求。使用您的配置，两者都会将文件缓存5分钟。您无法更改此行为，因为无法使CDN服务器的缓存无效，并且浏览器也不知道您的部署，即使它会收到通知并重新加载，也会从CDN获得相同的过时文件。

我不完全了解您的用例，但以下是可能的解决方案：

请确保不要删除旧文件，因此您需要保留main.x.js的任何版本至少在缓存持续时间内。您可以使用Cloud Storage在部署时上传文件。
向客户端添加后备广告。如果main.1.js给出404，请增加数字并尝试main.2.js
保持名称稳定，例如main.js
将main.js的内容添加到云函数的响应正文中。这样，您可以确保云功能响应和main.x.js的内容一起缓存并一起重新加载
删除高速缓存控制标头。这将导致功能上的流量增加，从而导致成本增加。
还要更改您的函数名称或在部署时对其进行重写，以导致高速缓存未命中

使部署的Google Cloud Function的Firebase缓存无效

1 个答案: