App braucht Konsistenzkontrolle? Cosmos-DB-Konsistenzstufe ändern

Ein Kunde ändert einen Produktpreis und liest ihn anschließend erneut. Cosmos DB hält mehrere Datenkopien, die Änderungen zu unterschiedlichen Zeitpunkten erhalten können. Die Konsistenzstufe bestimmt, wie aktuell und geordnet ein Leseergebnis sein muss. Session lässt eine Client-Sitzung ihre eigenen Schreibvorgänge lesen; Eventual erlaubt vorübergehend ältere Werte, während die Kopien aufholen.

Verwende cosmos-ctappeus aus dem Trip zur Kontoerstellung in rg-cloudtrips-cosmos-test-eus. Diese Übung verwendet ausschließlich das Portal.

Auf Eventual wechseln

Öffne cosmos-ctappeus → Default consistency. Merke dir die aktuelle Einstellung, wähle Eventual und anschließend Save. Warte auf den Abschluss und öffne die Seite erneut.

Prüfe, dass Eventual ausgewählt bleibt. Lesezugriffe können damit einen älteren Wert liefern; sobald Änderungen enden, gleichen sich die Replikate an. Das kann für eine Katalogansicht passen, die eine kurze Verzögerung toleriert.

Session wiederherstellen

Wähle auf derselben Seite Session → Save. Warte auf den Abschluss und öffne die Seite erneut.

Prüfe, dass Session ausgewählt bleibt. Cosmos-SDKs verwalten Session-Tokens, damit spätere Lesezugriffe derselben Sitzung ihre früheren Schreibvorgänge berücksichtigen. Andere Sitzungen können während der Replikation weiterhin ältere Werte sehen.

Die Screenshots bestätigen die gespeicherte Kontoeinstellung. Ob ein älterer Wert sichtbar wird, hängt von Abfragezeitpunkt und Replikation ab; diese Portal-Übung mit einer Region kann bei beiden Einstellungen den neuesten Wert zeigen.

Eine Konsistenzstufe wählen

Beginne für die meisten interaktiven Apps mit Session. Wähle eine andere Stufe, wenn du konkrete Anforderungen an Aktualität oder Reihenfolge hast.

Stufe	Garantie	Wann verwenden?
Strong	Lesezugriffe liefern den zuletzt bestätigten Wert.	Entscheidungen brauchen den neuesten gespeicherten Zustand.
Bounded staleness	Lesezugriffe dürfen innerhalb einer konfigurierten Zeit- oder Versionsgrenze zurückliegen.	Regionale Leser brauchen eine definierte maximale Verzögerung.
Session	Innerhalb einer Client-Sitzung siehst du eigene Schreibvorgänge und erhältst konsistente Leseergebnisse.	Warenkörbe, Profile, interaktive Apps.
Consistent prefix	Änderungen erscheinen in ihrer Schreibreihenfolge, gegebenenfalls verzögert.	Leser brauchen eine geordnete Folge und tolerieren Verzögerungen.
Eventual	Kopien gleichen sich an, sobald Schreibvorgänge enden; Aktualität und Reihenfolge können zwischenzeitlich variieren.	Ungefähre Zähler oder Anzeigen, die ältere Werte tolerieren.

Abwägung: Strong und Bounded staleness benötigen ungefähr doppelt so viele Request Units wie vergleichbare Session-Lesezugriffe. Strong erhöht außerdem die regionsübergreifende Schreiblatenz und erfordert eine einzelne Schreibregion.

Eine Session wird hier vom Datenbank-SDK über Session-Tokens verfolgt; die Anmeldesitzung deiner Website ist ein eigenständiges Konzept.

Lasse Session ausgewählt und behalte das Konto für den nächsten Trip. Diese Übung erstellt keine zusätzlichen Ressourcen.