谷歌云存储元数据更新

Posted 2023-02-16

【中文标题】谷歌云存储元数据更新

【英文标题】：Google Cloud Storage metadata updates

【发布时间】：2020-08-04 13:21:21

【问题描述】：

关于 GCS 中元数据更新通知的性质，我有一个由两部分组成的问题。 // For the mods: if I should split this into two, let me know and I will.

我在 Google Cloud Storage 中有一个存储桶，为对象元数据更改配置了 Pub/Sub 通知。我经常得到双倍元数据更新，似乎不知从何而来。发生的情况是，在某一时刻，Cloud Run 容器读取通知指定的对象并执行一些导致 a) 正在添加一个新文件。 b) 正在发送电子邮件。 这应该是它的结束。

但是，应用程序。 10 分钟后，针对同一对象触发第二个通知，metageneration 增加，但通知对象中没有明显的实际更改。 奇怪的是，ETag 似乎变化很小（CJ+2tfvk+egCEG0 -> CJ+2tfvk+egCEG4），但 CRC32C 和 MD5 校验和保持不变 - 从没有写入对象的意义上说这是正确的。

问题是双重的，那么： - 当没有设置/更新元数据时，metageneration 属性的增量究竟是什么？ - 如果基础数据没有改变，ETag 如何改变，如校验和所示（我猜文档确实说“只要基础数据发生变化，它们就会改变”[1]，这并不严格意味着它们不能改变） .

---

1：https://cloud.google.com/storage/docs/hashes-etags#_ETags

【问题讨论】：

如果元代数增加，最可能的原因是从某处显式调用以某种方式更新元数据（可能在 ACL 中或某处不明显）。考虑启用 Stackdriver 或存储桶访问日志，以验证没有来自某个地方的额外更新调用。

对于您提到的第二个问题，完整的文档引用是users should make no assumptions about those ETags except that they will change whenever the underlying data changes，因此，事实上，您不能假设 ETag 不会改变，因为这不能保证。

【参考方案1】：

正如@Brandon Yarbrough 所评论的，如果metageneration 数字增加，最可能的原因是从某个意外的地方显式调用以某种方式更新元数据，并且验证没有执行额外更新调用的方法是通过启用 Stackdriver 或存储桶访问日志。

关于 ETag 更改，ETag documentation on Cloud Storage 声明

用户不应对这些 ETag 做出任何假设，除非基础数据发生变化时它们会发生变化。

这表明，唯一可以保证 ETag 将被更改的场景是数据更改，但是，其他事件也可能触发 ETag 更改，因此您不应将 ETags 用作文件更改的参考。