Cloud Storage-Konsistenz

Auf dieser Seite wird gezeigt, welche Cloud Storage-Vorgänge unter „Strikte Konsistenz“ und welche unter „Eventual Consistency“ fallen. 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 folgenden Vorgängen eine strikte globale Konsistenz:

Bucket-Auflistung
Bucket lesen nach Erstellen
Bucket lesen nach Metadatenaktualisierung
Bucket lesen nach Löschen
Objekt lesen nach Schreiben
Objekt lesen nach Metadatenaktualisierung
Objekt lesen nach Löschen
Objektauflistung

Wenn Sie ein Objekt nach 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 Ihre Schreibanfrage erfolgreich beantwortet wurde. Dies gilt für alle Buckets und Speicherklassen sowie sowohl für das Erstellen neuer Objekte als auch für das Ersetzen vorhandener Objekte. Cloud Storage bietet außerdem Konsistenz beim Lesen nach Erstellen, Lesen nach Metadatenaktualisierung, Lesen nach Löschen und beim Auflisten von Ressourcen wie Ordner und verwaltete Ordner.

Da Schreibvorgänge strikt konsistent sind, erhalten Sie nach einem „Lesen nach Schreiben“- oder „Lesen nach Metadatenaktualisierung“-Vorgang in keinem Fall die Antwort 404 Not Found oder veraltete Daten, auch nicht für Buckets, die sich in zwei Regionen oder Multiregionen befinden. Im seltenen Fall, dass Ihre Daten noch nicht über Regionen hinweg repliziert wurden, der Standort, an den Ihr Objekt zuerst geschrieben wurde, aber nicht mehr verfügbar ist, wird bei dem Versuch, 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 nach einer erfolgreich ausgeführten 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 vorhanden ist, 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 strikt konsistent, die Umsetzung der damit verbundenen Änderung der Konfiguration für Buckets kann aber 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 aufheben
Buckets nach dem Löschen neu erstellen

Es dauert etwa eine Minute, bis diese Vorgänge wirksam werden. In einigen Fällen kann es einige Minuten länger dauern.

Beispiel für ein Verhalten, das sich aus einer Eventual Consistency ergeben kann: Wenn Sie den Zugriff eines Nutzers auf ein Bucket aufheben, 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.

Es kann einige Minuten dauern, bis auf neu erstellte Buckets zugegriffen werden kann.

Cachesteuerung und Konsistenz

Im Cache gespeicherte Objekte, die öffentlich lesbar sind, weisen möglicherweise keine starke Konsistenz auf. Wenn Sie das Speichern eines Objekts im Cache erlauben und sich das Objekt im Cache befindet, während es aktualisiert oder gelöscht wird, wird dieser Vorgang erst nach Ablauf der Aufbewahrungsdauer des Objekts im Cache ausgeführt.

Die Aufbewahrungsdauer eines Objekts im Cache wird durch die zugehörigen -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. Bei der Festlegung der Cache-Control-Metadaten bestimmen Sie die Konsistenz der Objekte im Cache. Anfragen für ein Objekt können darüber hinaus einen eigenen Cache-Control-Header enthalten. Cloud Storage ignoriert solche Header, wenn sie festgelegt wurden, um im Cache gespeicherte Inhalte zu vermeiden.

Atomare Vorgänge

Cloud Storage bietet Atomaritätsgarantien für die meisten Vorgänge mit einzelnen Objekten, z. B. das Hochladen von Objekten, das Aktualisieren von Objektmetadaten oder das Überschreiben und Löschen von Objekten.

Batchanfragen, bei denen einzelne Vorgänge in einer einzigen Anfrage zusammengefasst werden, sind nicht atomar, da einige der im Batch enthaltenen Vorgänge fehlschlagen können, während andere erfolgreich sein können.

Caching kann dazu führen, dass Sie veraltete Versionen eines Objekts erhalten. Wenn Sie Bereichslesevorgänge ohne Angabe einer Generierungsnummer ausführen, können Ihre Daten beschädigt werden, wenn das Objekt zwischen aufeinanderfolgenden Bereichslesevorgängen überschrieben wird. Als Best Practice sollten Sie mit Vorbedingungen dafür sorgen, dass Sie die richtige Objektversion abrufen.