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:

  • Lesen nach Schreiben
  • Lesen nach Metadatenaktualisierung
  • 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. Das gilt für alle Speicherklassen und alle Bucket. Es gilt sowohl für das Erstellen neuer 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 (einschließlich Überschreiben eines vorhandenen Objekts), das Aktualisieren der Metadaten eines Objekts, das Ersetzen eines Objekts und das Löschen eines Objekts.

Batchanfragen sind nicht garantiert atomar. Einzelne Vorgänge innerhalb einer Batchanfrage können atomar sein, aber es kann nicht garantiert werden, dass alle Vorgänge innerhalb der Batchanfrage als Gruppe atomar sind, da einige der Vorgänge erfolgreich sein können, während andere fehlschlagen.

In einigen Fällen wird möglicherweise eine ältere Version eines Objekts abgerufen, z. B. wenn im Cache gespeicherte Daten veraltet sind oder wenn Sie einen Bereichsabruf ausführen, ohne eine Generierungsnummer anzugeben, wodurch das Objekt, das Sie abrufen möchten, überschrieben wird. Verwenden Sie Vorbedingungen, um sicherzustellen, dass Sie die richtige Objektversion abrufen.

Nächste Schritte