我们设置了云功能，可以监听云存储桶以进行更改。我们今天早上注意到，几个小时它没有开火（我们每小时都有一个文件上传到那个桶，所以它应该每小时运行一次）。然后，大约上午8点18分，它开了好几次，“赶上”它立即错过的火灾。举例说明：
{Normal runs}
4:50am - 1.csv uploaded to GCS bucket
4:50am - Cloud function tirggers on 1.csv
5:50am - 2.csv uploaded to GCS bucket
5:50am - Cloud function triggers on 2.csv
{This is where things get weird}
6:50am - 3.csv uploaded to GCS bucket
7:51am - 4.csv uploaded to GCS bucket
8:18am - Cloud function triggers on 3.csv
8:18am - Cloud function triggers on 4.csv
{Back to normal}
8:51am - 5.csv uploaded to GCS bucket
8:51am - Cloud function triggers on 5.csv
这是我们第一次注意到这种行为。 GCP状态页面表示云功能没有中断，但该服务仍处于测试阶段。
有没有人遇到这种断断续续的可靠性？如果这种情况经常发生，我们将不得不重新考虑将其作为我们架构的一部分。
我应该注意云功能中的代码非常简单。在开头有一个console.log权限，我们用它来跟踪它的运行时间（以及哪个文件）。过去两周内没有发生任何错误。
答案 0 :(得分：1)
来自GCS文档，there's no delivery promise。
对象更改通知将尝试向其发送通知 您的申请以可靠的方式进行。但是，请注意 通知可以无限期延迟，而且及时性不是 保证。
使用GCS Cloud Pub/Sub Notifications，您可以更可靠地将云功能连接到Cloud Pub/Sub triggers;但是，Cloud Pub / Sub Notifications也没有delivery SLA。
看起来如果您需要在一定时间内收到通知，则无法保证，但它可能会在大部分时间内正常工作。