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

Question

我最近通过Cloud Functions和Firebase Hosting实现了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一起缓存并一起重新加载
• 删除缓存控制标头。这将导致更高的功能流量，从而导致更高的成本。
• 还要更改您的函数名称或其在部署时重写以导致缓存未命中