Cloud Storage-Konsistenz

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 folgenden Vorgängen eine starke globale Konsistenz:

  • Bucket-Auflistung
  • Bucket-Lesevorgang nach Erstellung
  • Bucket-Lesen nach Metadatenaktualisierung
  • Bucket-Lesen nach Löschen
  • Lesen nach Schreiben von Objekten
  • Objekt nach Metadatenaktualisierung lesen
  • Objekt nach dem Löschen gelesen
  • 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 alle Speicherklassen und sowohl für das Erstellen neuer Objekte als auch für das Ersetzen vorhandener Objekte. Cloud Storage bietet außerdem Konsistenz beim Lesen nach dem Erstellen, Lesen nach der Aktualisierung von Metadaten, Lesen nach dem Löschen und Auflisten von Ressourcen wie Ordnern und verwalteten Ordnern.

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
  • 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.

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.

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 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 Atomizitätsgarantien für die meisten Vorgänge mit einzelnen Objekten, z. B. das Hochladen, Aktualisieren von Metadaten, Ü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 sind.

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 Vorbedingungen verwenden, um sicherzustellen, dass Sie die richtige Objektversion abrufen.

Nächste Schritte