一致性

本页面介绍哪些 Cloud Storage 操作具有高度一致性以及哪些 Cloud Storage 操作具有最终一致性。对于可缓存且可公开读取的对象，您需要控制对象操作的一致程度。

具备高度一致性的操作

Cloud Storage 为以下操作提供了高度的全球一致性：

  • 写后读 (Read-after-write)
  • 元数据更新后读取 (Read-after-metadata-update)
  • 删除后读取 (Read-after-delete)
  • 列出存储桶
  • 列出对象

将对象写入 Cloud Storage 后（例如上传、编写或复制对象时），一旦收到写入请求的成功响应，对象即可立即进行读取和元数据操作。这适用于所有存储桶和所有存储类别，并且适用于创建新对象和替换现有对象。

由于写入操作具有强一致性，因此，执行写后读 (read-after-write) 或元数据更新后读取 (read-after-metadata-update) 操作时，您从不会收到 404 Not Found 响应或过时数据，即使是对于位于双区域或多区域的存储桶也是如此。在极少数情况下，如果您的数据尚未跨区域复制，但对象首次写入的位置变得不可用，则尝试访问该对象时将返回可重试的 500 错误响应。

对象删除操作也具有很强的全球一致性。如果删除请求成功，立即尝试下载对象或其元数据将导致 404 Not Found 状态代码。收到 404 错误的原因是，删除操作成功后对象将不再存在。

列出存储桶和列出对象的操作具有高度一致性：当您创建存储桶或对象并立即执行相关 list 操作时，新创建的存储桶或对象会显示在返回的列表中。

对于存储桶，虽然元数据更新后读取 (read-after-metadata-update) 操作的元数据更新具有强一致性，但产生的配置更改可能需要一段时间才能传播。例如，如果您为存储桶启用了对象版本控制，则应至少等待 30 秒才能删除或替换对象。

HMAC 密钥也是如此，从您请求更改密钥状态到状态更改生效之间，最多会有 3 分钟的延迟。 例如，如果您停用 HMAC 密钥，则应等待至少 3 分钟，然后再发出删除密钥的请求，因为前 3 分钟内进行请求可能会失败。

具备最终一致性的操作

以下操作具有最终一致性：

  • 授予对资源的访问权限或撤消对资源的访问权限。

这些操作通常需要大约一分钟才能生效。在某些情况下，可能需要几分钟时间。

以最终一致性引发的行为为例，如果您移除了某个用户对存储桶的访问权限，这项更改会立即反映在存储桶的元数据中；但在短时间内，该用户可能仍然可以访问存储桶。

缓存控制和一致性

可公开读取的缓存对象可能不会呈现强一致性。如果您允许某个对象进行缓存，则当您更新或删除处于缓存中的对象时，除非缓存有效期结束，否则系统不会更新或删除缓存的对象。

对象的缓存有效期由与该对象关联的 Cache-Control 元数据定义。Cache-Control 元数据可使用 Cache-Control 请求标头设置，初次上传对象或后续更新对象元数据时会包含此标头。通过控制 Cache-Control 元数据，您还可以控制缓存对象的一致程度。此外，尽管对象请求可以包含自己的 Cache-Control 标头，但如果这些标头被设置为避免缓存内容，Cloud Storage 则会忽略它们。

原子操作

Cloud Storage 为涉及个别对象的大多数操作（例如上传对象 [包括覆盖现有对象]、更新对象元数据、替换对象和删除对象）提供了原子性保证。

批量请求不一定是原子化请求。虽然批处理请求中的单个操作可以是原子操作，但无法保证批处理请求中的所有操作作为一组操作是原子操作，因为其中一些操作可能会成功，而其他操作可能会失败。

在某些情况下，您可能会提取对象的旧版本，例如，当缓存数据过时时，或者当您执行范围读取但未指定世代号时，您打算提取的对象会被覆盖。最佳实践是使用前提条件来确保您提取的是正确的对象版本。

后续步骤