Auf dieser Seite wird beschrieben, welche Cloud Storage-Vorgänge strikt konsistent und welche letztendlich konsistent sind. Bei cachefähigen, öffentlich lesbaren Objekten können Sie den Konsistenzgrad der Vorgänge für die Objekte bestimmen.
Stark konsistente Vorgänge
Cloud Storage bietet bei den folgenden Vorgängen eine starke globale Konsistenz:
- Lesen nach Schreiben
- Read-after-metadata-update
- Lesen nach Löschen
- Bucket-Auflistung
- Objektauflistung
Wenn Sie ein Objekt in Cloud Storage schreiben, z. B. wenn Sie ein Objekt hochladen, erstellen oder kopieren, steht das Objekt sofort für Lese- und Metadatenvorgänge zur Verfügung, sobald Sie eine Erfolgsantwort auf Ihre Schreibanfrage erhalten. Dies gilt für alle Buckets und Speicherklassen und gilt sowohl für das Erstellen neuer Objekte als auch für das Ersetzen vorhandener Objekte.
Da Schreibvorgänge strikt konsistent sind, erhalten Sie nie die Antwort 404 Not Found
oder veraltete Daten nach einem „Lesen nach Schreiben“- oder „Lesen nach Metadatenaktualisierung“-Vorgang, auch nicht für Buckets, die sich in Dual- -Regionen oder Multiregionenbefinden. In dem seltenen Fall, in dem Ihre Daten noch nicht über Regionen hinweg repliziert wurden, aber der Standort, an den Ihr Objekt zuerst geschrieben wurde, nicht mehr verfügbar ist, wird bei Versuchen, auf das Objekt zuzugreifen, eine wiederholbare 500
-Fehlerantwort zurückgegeben.
Die starke globale Konsistenz erstreckt sich auch auf Löschvorgänge für Objekte. Wenn bei einer erfolgreichen Löschanfrage direkt danach versucht wird, das Objekt oder dessen Metadaten herunterzuladen, wird der Statuscode 404 Not Found
ausgegeben. Der Fehler 404
wird angezeigt, weil das Objekt nicht mehr existiert, nachdem der Löschvorgang erfolgreich war.
Bucket-Auflistung und Objektauflistung sind strikt konsistent: Wenn Sie einen Bucket oder ein Objekt erstellen und dann sofort den relevanten list
-Vorgang ausführen, wird der neu erstellte Bucket oder das neu erstellte Objekt in der zurückgegebenen Liste angezeigt.
Metadatenaktualisierungen sind zwar bei "Lesen nach Metadatenaktualisierung"-Vorgängen stark konsistent, aber die Umsetzung der daraus resultierenden Konfigurationsänderungen für Buckets kann etwas Zeit in Anspruch nehmen. Wenn Sie beispielsweise die Objektversionsverwaltung für einen Bucket aktivieren, sollten Sie mindestens 30 Sekunden warten, bevor Sie Objekte löschen oder ersetzen.
Ebenso gibt es für HMAC-Schlüssel eine Verzögerung von bis zu drei Minuten zwischen dem Zeitpunkt, zu dem Sie die Anfrage zum Ändern des Schlüsselstatus senden, und dem Zeitpunkt, zu dem die Statusänderung wirksam wird. Wenn Sie beispielsweise einen HMAC-Schlüssel deaktivieren, sollten Sie mindestens drei Minuten warten, bevor Sie eine Anfrage zum Löschen des Schlüssels senden. Andernfalls könnte der gewünschte Vorgang in den ersten drei Minuten fehlschlagen.
Letztendlich konsistente Vorgänge
Der folgende Vorgang ist letztendlich konsistent:
- Zugriff auf Ressourcen gewähren oder entziehen
Es dauert etwa eine Minute, bis diese Vorgänge wirksam werden. In einigen Fällen kann es einige Minuten länger dauern.
Hier ein Beispiel für ein Verhalten, das sich aus einer Eventual Consistency ergeben kann. Wenn Sie den Zugriff eines Nutzers auf ein Bucket entfernen, wird diese Änderung in den Metadaten des Buckets sofort übernommen. Der Nutzer kann jedoch für einen kurzen Zeitraum weiter Zugriff auf den Bucket haben.
Cachesteuerung und Konsistenz
Im Cache gespeicherte Objekte, die öffentlich lesbar sind, weisen möglicherweise keine starke Konsistenz auf. Wenn Sie die Speicherung eines Objekts im Cache zulassen und sich das Objekt dort befindet, während es aktualisiert oder gelöscht wird, wird es erst nach Ablauf seiner Aufbewahrungsdauer im Cache aktualisiert oder gelöscht.
Die Aufbewahrungsdauer eines Objekts im Cache wird durch die damit verbundenen Cache-Control
-Metadaten festgelegt. Die Cache-Control
-Metadaten können mithilfe des Anfrage-Headers Cache-Control
im ursprünglichen Upload des Objekts oder bei einer nachfolgenden Aktualisierung der Metadaten des Objekts festgelegt werden. Mit der Steuerung der Cache-Control
-Metadaten können Sie auch die Konsistenz der Objekte im Cache bestimmen. Anfragen für ein Objekt können darüber hinaus einen eigenen Cache-Control
-Header enthalten. Cloud Storage ignoriert solche Header, wenn sie eingestellt wurden, um zwischengespeicherte Inhalte zu vermeiden.
Atomare Vorgänge
Cloud Storage bietet Atomaritätsgarantien für die meisten Vorgänge, die einzelne Objekte betreffen, z. B. das Hochladen eines Objekts, das Aktualisieren der Metadaten eines Objekts und das Löschen eines Objekts. Vorgänge, die mehrere Objekte gleichzeitig betreffen, z. B. das Kopieren oder Umbenennen mehrerer Objekte, sind nicht atomar.
Nächste Schritte
- Mehr über die Anwendung von Vorbedingungen zum Verhindern von Race-Bedingungen erfahren
- Mehr über das Caching in Cloud Storage erfahren
- Mehr über Richtlinien für die Anforderungsrate und Zugriffsverteilung erfahren