由于写入操作具有强一致性，因此，执行对象写入后读取或对象元数据更新后读取操作时，您从不会收到 404 Not Found 响应或过时数据，即使是对于位于双区域或多区域的存储桶也是如此。在极少数情况下，如果您的数据尚未跨区域复制，但对象首次写入的位置变得不可用，则尝试访问该对象时将返回可重试的 500 错误响应。
对象删除操作也具有很强的全球一致性。如果删除请求成功，立即尝试下载对象或其元数据将导致 404 Not Found 状态代码。收到 404 错误的原因是，删除操作成功后对象将不再存在。
列出存储桶和列出对象的操作具有高度一致性：当您创建存储桶或对象并立即执行相关 list 操作时，新创建的存储桶或对象会显示在返回的列表中。
[[["易于理解","easyToUnderstand","thumb-up"],["解决了我的问题","solvedMyProblem","thumb-up"],["其他","otherUp","thumb-up"]],[["很难理解","hardToUnderstand","thumb-down"],["信息或示例代码不正确","incorrectInformationOrSampleCode","thumb-down"],["没有我需要的信息/示例","missingTheInformationSamplesINeed","thumb-down"],["翻译问题","translationIssue","thumb-down"],["其他","otherDown","thumb-down"]],["最后更新时间 (UTC)：2025-08-18。"],[],[],null,["# Cloud Storage consistency\n\nThis page explains which Cloud Storage operations are strongly consistent and\nwhich are eventually consistent. In the case of cacheable, publicly readable\nobjects, you control the degree to which operations on the objects are\nconsistent.\n\nStrongly consistent operations\n------------------------------\n\nCloud Storage provides strong global consistency for the following\noperations:\n\n- Bucket listing\n- Bucket read-after-create\n- Bucket read-after-metadata-update\n- Bucket read-after-delete\n- Object read-after-write\n- Object read-after-metadata-update\n- Object read-after-delete\n- Object listing\n\nWhen you write an object to Cloud Storage, such as when you upload,\ncompose, or copy an object, the object is immediately available for reading and\nmetadata operations as soon as you receive a success response to your write\nrequest. This is true for all buckets and for all storage classes, and\nthis applies to both creating new objects and replacing existing objects.\nCloud Storage also offers read-after-create, read-after-metadata-update,\nread-after-delete, and listing consistency for resources such as folders and\nmanaged folders.\n\nBecause writes are strongly consistent, you never receive a `404 Not Found`\nresponse or stale data for an object read-after-write or object\nread-after-metadata-update operation, even for buckets located in\n[dual-regions or multi-regions](/storage/docs/locations#available-locations). In the rare event where your data has\nnot yet been [replicated across regions](/storage/docs/availability-durability#cross-region-redundancy), but the location your object\nwas first written to becomes unavailable, attempts to access the object return\na [retryable](/storage/docs/retry-strategy) `500` error response.\n\nStrong global consistency also extends to deletion operations on objects. If a\ndeletion request succeeds, an immediate attempt to download the object or its\nmetadata results in a `404 Not Found` status code. You get the `404` error\nbecause the object no longer exists after the delete operation succeeds.\n\nBucket listing and object listing are strongly consistent: when you create a\nbucket or object and then immediately perform the relevant `list` operation, the\nnewly created bucket or object appears in the returned list.\n| **Important:** Cached objects that are publicly readable might not exhibit strong consistency. See [Cache control and consistency](#cache-control) for details.\n\nFor buckets, while metadata updates are strongly consistent for\nread-after-metadata-update operations, the resulting configuration changes may\ntake time to propagate. For example, if you enable [object versioning](/storage/docs/object-versioning) on a\nbucket, you should wait at least 30 seconds before deleting or replacing\nobjects.\n\nSimilarly for [HMAC keys](/storage/docs/authentication/hmackeys), there is a delay of up to 3 minutes between\nwhen you request to change the key state and when the state change takes effect.\nFor example, if you [disable an HMAC key](/storage/docs/authentication/managing-hmackeys#update), you should wait at least 3\nminutes before making a request to delete the key, because attempts to do so in\nthe first 3 minutes could fail.\n\nEventually consistent operations\n--------------------------------\n\nThe following operations are eventually consistent:\n\n- Granting access to or revoking access from resources.\n- Recreating buckets after deletion.\n\nIt typically takes about a minute for these operations to take effect. In some\ncases, it might take several minutes longer.\n\nAs an example of behavior that can arise from eventual consistency, if you\nremove a user's access to a bucket, this change is immediately reflected in the\nmetadata for the bucket; however, the user may still have access to the bucket\nfor a short period of time.\n\nBuckets that are recreated after deletion might take several minutes to become\naccessible.\n\nCache control and consistency\n-----------------------------\n\nCached objects that are publicly readable might not exhibit strong consistency.\nIf you allow an object to be cached, and the object is in the cache when it is\nupdated or deleted, the cached object is not updated or deleted until its\ncache lifetime expires.\n\nThe cache lifetime of an object is defined by the [`Cache-Control` metadata](/storage/docs/metadata#cache-control)\nassociated with the object. The `Cache-Control` metadata can be set using a\n`Cache-Control` request header included in the initial upload of the object,\nor in a subsequent [update to the metadata of the object](/storage/docs/viewing-editing-metadata#edit). Because you\ncontrol the `Cache-Control` metadata, you also control the degree to which\ncached objects are consistent. Moreover, while requests for\nthe object can include their own `Cache-Control` header, these headers are\nignored by Cloud Storage if they're set to avoid cached content.\n| **Note:** If you do not specify a cache lifetime, a publicly accessible object can be cached for up to 60 minutes.\n\nAtomic operations\n-----------------\n\nCloud Storage provides atomicity guarantees for most operations\ninvolving individual objects, such as uploading an object, updating an object's\nmetadata, overwriting an object, and deleting an object.\n\nBatch requests, which aggregate individual operations into a single request, are\nnot atomic, because it's possible for some of the operations contained within\nthe batch to fail while others succeed.\n\n[Caching](/storage/docs/caching) can cause you to receive stale versions of an object, and if you\n[perform ranged reads](/storage/docs/sliced-object-downloads) without specifying a generation number, your data\nmight become corrupted if the object becomes overwritten between successive\nranged reads. As a best practice, use [preconditions](/storage/docs/request-preconditions) to make sure you're\nfetching the correct object version.\n\nWhat's next\n-----------\n\n- Learn about using [preconditions](/storage/docs/request-preconditions) to prevent race conditions.\n- Learn more about [caching in Cloud Storage](/storage/docs/caching).\n- Learn about [request rate and access distribution guidelines](/storage/docs/request-rate)."]]
