[[["容易理解","easyToUnderstand","thumb-up"],["確實解決了我的問題","solvedMyProblem","thumb-up"],["其他","otherUp","thumb-up"]],[["難以理解","hardToUnderstand","thumb-down"],["資訊或程式碼範例有誤","incorrectInformationOrSampleCode","thumb-down"],["缺少我需要的資訊/範例","missingTheInformationSamplesINeed","thumb-down"],["翻譯問題","translationIssue","thumb-down"],["其他","otherDown","thumb-down"]],["上次更新時間：2025-09-05 (世界標準時間)。"],[],[],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)."]]
