IStateReplicator.ReplicateAsync Methode

Definition

Namespace:

System.Fabric

Assembly:

System.Fabric.dll

Paket:

Microsoft.ServiceFabric v9.1.1833

Repliziert Zustandsänderungen vom primären Replikat in die sekundären Replikate und erhält eine Quorumbestätigung, dass diese Zustandsänderungen angewendet wurden.

public System.Threading.Tasks.Task<long> ReplicateAsync (System.Fabric.OperationData operationData, System.Threading.CancellationToken cancellationToken, out long sequenceNumber);

abstract member ReplicateAsync : System.Fabric.OperationData * System.Threading.CancellationToken * int64 -> System.Threading.Tasks.Task<int64>

Public Function ReplicateAsync (operationData As OperationData, cancellationToken As CancellationToken, ByRef sequenceNumber As Long) As Task(Of Long)

Parameter

operationData

OperationData

Die OperationData , die die Zustandsänderung darstellt, die das primäre Replikat replizieren möchte.

cancellationToken

CancellationToken

Ein Schreibquorum von Replikaten, die verloren gegangen sind. Sie kann verwendet werden, um eine Benachrichtigung zu senden, dass der Vorgang abgebrochen werden soll. Beachten Sie, dass der Abbruch eine Empfehlung ist und dass der Vorgang möglicherweise trotzdem abgeschlossen wird, auch wenn er abgebrochen wird.

sequenceNumber

Int64

Long, die LSN des Vorgangs. Beachten Sie, dass dies derselbe Wert ist, der von der Aufgabe zurückgegeben wird. Die Bereitstellung als out-Parameter ist für Dienste nützlich, die den lokalen Schreibvorgang vorbereiten möchten, um nach Abschluss der Aufgabe einen Commit auszuführen.

Gibt zurück

Task<Int64>

Gibt Task<TResult> den Typ long zurück, die LSN des Vorgangs.

Ausnahmen

ArgumentException

Dies wird durch eine der folgenden Ursachen verursacht:

E_INVALIDARG wird zurückgegeben, wenn mindestens ein Argument ungültig ist.

FabricTransientException

FabricTransientException ist eine wiederholbare Ausnahme. Sie wird durch eine der folgenden Ursachen verursacht:

NoWriteQuorum wird zurückgegeben, wenn der Replizierer derzeit kein Schreibquorum aufweist.

ReconfigurationPending wird zurückgegeben, wenn der Replizierer über eine ausstehende Neukonfiguration verfügt.

ReplicationQueueFull wird zurückgegeben, wenn die Replikationswarteschlange voll ist.

FabricNotPrimaryException

FabricNotPrimaryException wird durch eine der folgenden Ursachen verursacht;

NotPrimary wird zurückgegeben, wenn der Replizierer über eine ausstehende Neukonfiguration verfügt.

FabricObjectClosedException

FabricObjectClosedException wird durch eine der folgenden Ursachen verursacht;

ObjectClosed wird zurückgegeben, wenn der Replizierer geschlossen wurde.

OperationCanceledException

OperationCanceledException wird durch eine der folgenden Ursachen verursacht;

E_ABORT, wenn der Replizierer einen Inflight-Replikationsvorgang abbricht.

Hinweise

Die Replikation auf dem primären Replikat erzeugt die Objekte, IOperation die das sekundäre Replikat aus dem Replikationsdatenstrom über GetReplicationStream()erhält, gefolgt von GetOperationAsync(CancellationToken).

Das primäre Replikat hat viele Aufgaben, die sich auf Aktualisierungen des Prozesszustands beziehen. Die folgenden Schritte zeigen die allgemeine Abfolge von Ereignissen, die ein primäres Replikat behandeln muss, um eine Änderung zu replizieren und zu bestätigen.

Teil 1: Behandeln eingehender Anforderungen: Empfangsanforderung: Write(x) – Service empfängt eine Schreibanforderung, x. CheckArguments: Der Dienst überprüft die Argumente der Anforderung. Diese Überprüfung trägt dazu bei, die Konsistenz des Dienststatus sicherzustellen.

Aktuellen Zustand überprüfen: Der Dienst überprüft seinen aktuellen Zustand, um sicherzustellen, dass der Vorgang gültig ist und ausgeführt werden kann oder sollte. Diese Überprüfung trägt auch dazu bei, die Datenkonsistenz sicherzustellen. Sie wird vom Dienstcode ausgeführt.

Abrufen von Sperren: Der Dienst sollte die erforderlichen Sperren abrufen, um zu verhindern, dass gleichzeitig zusätzliche Vorgänge ausgeführt werden. Dieser Vorgang trägt dazu bei, Isolation und Konsistenz sicherzustellen.

Versuchsvorgang (optional): Der Dienst kann den Vorgang lokal versuchen. Dieser Schritt reserviert und reserviert Speicherplatz und führt alle erforderlichen Berechnungen durch. Dieser Schritt umfasst alles außer dem tatsächlichen Commit des Ergebnisses. Dieser Vorgang verbessert die Dauerhaftigkeit des Vorgangs und macht spätere Fehler sehr unwahrscheinlich.

Herstellen von OperationData: Ein OperationData -Objekt ist die Darstellung des Write(x), der dem Dienst angezeigt wurde. Das OperationData -Objekt enthält die Zustandsänderung, die mit Bestätigung vom primären Replikat auf die sekundären Replikate übertragen werden soll. Die Daten, die der Dienst in OperationData platziert, definieren das atomische Update, das von an FabricReplicator die sekundären Replikate übertragen wird. Beachten Sie, dass für das Erstellen des OperationData Objekts mindestens ein Bytearray erforderlich ist. Der Dienst muss die Zustandsänderung selbst bestimmen und serialisieren und diesen Satz von Bytes dann über ReplicateAsync(OperationData, CancellationToken, Int64)an den FabricReplicator bereitstellen. Der Dienst sendet den Vorgang an den FabricReplicator und empfängt im Gegenzug eine logische Sequenznummer (Logical Sequence Number, LSN). Die LSN ist die Identität für den Vorgang und hilft sowohl dem Dienst als auch service Fabric sicherzustellen, dass Vorgänge immer überall in derselben Reihenfolge angewendet werden. Der Dienst sollte die OperationData zusammen mit seiner LSN in einer geordneten Liste von Flugvorgängen aufzeichnen. Dadurch wird sichergestellt, dass die Vorgänge nach Abschluss konsistent in der richtigen Reihenfolge angewendet werden können.

Freigabesperren: Fahren Sie mit der Verarbeitung fort oder warten Sie auf weitere Anforderungen.

Teil 2: Abschließen von Anforderungen und Antworten: Das primäre Replikat empfängt einen Rückruf, der angibt, dass der Vorgang angewendet wurde. ReplicateAsync ist abgeschlossen. Dieser Rückruf gibt an, dass der Vorgang von einem Quorum der Replikate in der Replikatmenge bestätigt wurde. Wenn das primäre Replikat diesen Rückruf empfängt, sollte es die folgenden Aktionen ausführen:

Suchen Sie den entsprechenden Vorgang, der durch den langen LSN angegeben wird, der von ReplicateAsync in der In-Flight-Liste des Diensts zurückgegeben wird, und markieren Sie ihn als "QuorumAck'd".

Beginnen Sie nun mit dem ersten Vorgang in der In-Flight-Liste, durchlaufen Sie die Liste, und committen Sie alle QuorumAck'd-Vorgänge lokal, schließen Sie alle Änderungen am lokalen Zustand ab, und markieren Sie die Zustandsänderungen mit der entsprechenden LSN, bis der erste unvollständige Vorgang gefunden wird. Dadurch wird sichergestellt, dass die Reihenfolge beibehalten wird (Konsistenz) und dass die Vorgänge tatsächlich angewendet werden. Dies nutzt die bisherigen Dauerhaftigkeits- und Isolationspräparate. Hinweis: Die meisten Dienste sollten den letzten committeten LSN-Wert zwischenspeichern, damit für Antworten auf den GetLastCommittedSequenceNumber() nicht der tatsächliche Speicher nach der größten LSN abfragt werden muss.

Wenn ein Vorgang erfolgreich auf dem primären Replikat committet wurde, kann das primäre Replikat nun an den Client antworten, der den Aufruf initiiert hat, und den Vorgang aus der Liste der In-Flight-Replikate entfernen. Warten Sie weiterhin auf den nächsten Quorumbestätigungsrückruf.