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

Question

我最近使用 Cloud Functions 和 Firebase 托管实现了 SSR。

当构建 JS 包时，它会收到一个缓存突发后缀 (main.1.js)。

在我的函数中，我有以下代码用于缓存云函数的结果

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告诉处理请求的任何一方（主要是用户的浏览器和谷歌的CDN服务器，但也可以是例如用户正在使用的代理）如何缓存请求。使用您的配置，两者都会将文件缓存 5 分钟。您无法更改此行为，因为无法使 CDN 服务器的缓存失效，并且浏览器也不知道您的部署，即使它会收到通知并重新加载，它也会从 CDN 获得相同的过时文件。

我不完全了解您的用例，但这里有一些可能的解决方案：

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