Echtzeitkonsistenz
Aufgrund der Natur einiger verteilter Systeme lässt sich Echtzeitkonsistenz zwischen Anforderungen nur schwer implizit erzwingen. Eine Lösung für dieses Problem besteht darin, Protokollunterstützung in Form von mehreren Synchronisierungstoken zuzulassen. Synchronisierungstoken sind optional.
Erste Anforderung
Um Echtzeitkonsistenz zwischen verschiedenen Clientinstanzen und Anforderungen zu gewährleisten, verwenden Sie optionale Sync-Token
-Anforderungs- und Antwortheader.
Syntax:
Sync-Token: <id>=<value>;sn=<sn>
Parameter | BESCHREIBUNG |
---|---|
<id> |
Token-ID (nicht transparent) |
<value> |
Der Tokenwert (nicht transparent). Erlaubt Base64-codierte Zeichenfolgen. |
<sn> |
Die Tokensequenznummer (Version). Ein höherer Wert bedeutet eine neuere Version desselben Tokens. Ermöglicht bessere Parallelität und Clientzwischenspeicherung. Der Client kann nur die letzte Version des Tokens verwenden, da Tokenversionen inklusiv sind. Dieser Parameter ist für Anforderungen nicht erforderlich. |
Antwort
Der Dienst stellt mit jeder Antwort einen Sync-Token
-Header bereit.
Sync-Token: jtqGc1I4=MDoyOA==;sn=28
Nachfolgende Anforderungen
Für jede nachfolgende Anforderung ist eine in Echtzeit konsistente Antwort in Bezug auf das bereitgestellte Sync-Token
garantiert.
Sync-Token: <id>=<value>
Wenn Sie den Sync-Token
-Header in der Anforderung auslassen, ist es möglich, dass der Dienst während eines kurzen Zeitraums (maximal einige Sekunden) mit zwischengespeicherten Daten antwortet, bevor die interne Festlegung erfolgt. Dieses Verhalten kann zu inkonsistenten Lesevorgängen führen, wenn direkt vor dem Lesevorgang Änderungen aufgetreten sind.
Mehrere Synchronisierungstoken
Der Server könnte bei einer einzelnen Anforderung mit mehreren Synchronisierungstoken antworten. Um Echtzeitkonsistenz für die nächste Anforderung beizubehalten, muss der Client mit allen empfangenen Synchronisierungstoken antworten. Mehrere Headerwerte müssen durch Kommas getrennt sein.
Sync-Token: <token1-id>=<value>,<token2-id>=<value>
Feedback
https://aka.ms/ContentUserFeedback.
Bald verfügbar: Im Laufe des Jahres 2024 werden wir GitHub-Issues stufenweise als Feedbackmechanismus für Inhalte abbauen und durch ein neues Feedbacksystem ersetzen. Weitere Informationen finden Sie unterFeedback senden und anzeigen für