IStateReplicator.ReplicateAsync Méthode

Définition

Espace de noms:

System.Fabric

Assembly:

System.Fabric.dll

Paquet:

Microsoft.ServiceFabric v9.1.1833

Réplique les modifications d’état des réplica primaires vers les réplicas secondaires et reçoit un accusé de réception de quorum indiquant que ces modifications d’état ont été appliquées.

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)

Paramètres

operationData

OperationData

OperationData qui représente le changement d’état que le réplica principal souhaite répliquer.

cancellationToken

CancellationToken

Quorum d’écriture des réplicas qui ont été perdus. Il peut être utilisé pour envoyer une notification indiquant que l’opération doit être annulée. Notez que l’annulation est un avertissement et que l’opération peut toujours être terminée même si elle est annulée.

sequenceNumber

Int64

Long, LSN de l’opération. Notez qu’il s’agit de la même valeur que celle retournée par la tâche. Le fait de le fournir en tant que paramètre out est utile pour les services qui souhaitent préparer l’écriture locale à valider une fois la tâche terminée.

Retours

Task<Int64>

Retourne Task<TResult> de type long, le LSN de l’opération.

Exceptions

ArgumentException

Causé par l’un des éléments suivants :

E_INVALIDARG est retourné lorsqu’un ou plusieurs arguments ne sont pas valides.

FabricTransientException

FabricTransientException est une exception pouvant être retentée. Elle est causée par l’une des causes suivantes :

NoWriteQuorum est retourné lorsque le réplicateur n’a pas de quorum d’écriture.

ReconfigurationPending est retourné lorsque le réplicateur a une reconfiguration en attente.

ReplicationQueueFull est retourné lorsque la file d’attente du réplicateur est pleine.

FabricNotPrimaryException

FabricNotPrimaryException est dû à l’une des causes suivantes :

NotPrimary est retourné lorsque le réplicateur a une reconfiguration en attente.

FabricObjectClosedException

FabricObjectClosedException est dû à l’une des causes suivantes :

ObjectClosed est retourné lorsque le réplicateur a été fermé.

OperationCanceledException

OperationCanceledException est dû à l’une des causes suivantes :

E_ABORT lorsque le réplicateur annule une opération de réplication en vol.

Remarques

La réplication au niveau du réplica primaire produit les objets qui implémentent IOperation que le réplica secondaire obtient à partir du flux de réplication via GetReplicationStream(), qui est suivi de GetOperationAsync(CancellationToken).

Le réplica principal a de nombreuses tâches liées au traitement des mises à jour d’état. Les étapes suivantes montrent la séquence générale d’événements qu’un réplica principal doit gérer pour répliquer et accuser réception d’une modification.

Partie 1 : Gestion des demandes entrantes : Réception de la demande : Write(x) – Le service reçoit une demande d’écriture, x. CheckArguments : le service vérifie les arguments de la demande. Cette case activée permet de garantir la cohérence de l’état du service.

Vérifier l’état actuel : le service examine son état actuel pour s’assurer que l’opération est valide et peut ou doit être effectuée. Cette case activée permet également de garantir la cohérence des données. Elle est effectuée par le code de service.

Acquérir des verrous : le service doit acquérir les verrous nécessaires pour empêcher des opérations supplémentaires de se produire en même temps. Cette opération permet de garantir l’isolation et la cohérence.

Opération de tentative (facultatif) : le service peut tenter l’opération localement. Cette étape réserve et alloue de l’espace et effectue tous les calculs nécessaires. Cette étape inclut tout sauf la validation réelle du résultat. Cette opération améliore la durabilité de l’opération et rend les défaillances ultérieures très peu probables.

Fabriquer l’OperationData : un OperationData objet est la représentation de l’objet Write(x) qui a été présenté au service. L’objet OperationData contient le changement d’état à transférer avec accusé de réception du réplica principal vers les réplicas secondaires. Les données que le service place dans OperationData définissent la mise à jour atomique que le FabricReplicator transfère aux réplicas secondaires. Notez que la création de l’objet OperationData nécessite un ou plusieurs tableaux d’octets. Le service doit lui-même déterminer et sérialiser le changement d’état, puis fournir cet ensemble d’octets à FabricReplicator via ReplicateAsync(OperationData, CancellationToken, Int64). Le service envoie l’opération à FabricReplicator et reçoit un numéro séquentiel logique (LSN) en retour. Le LSN est l’identité de l’opération et permet au service et à Service Fabric de s’assurer que les opérations sont toujours appliquées dans le même ordre partout. Le service doit enregistrer l’OperationData avec son numéro LSN dans une liste ordonnée d’opérations en vol. Cela garantit que lorsque les opérations sont terminées, elles peuvent être appliquées de manière cohérente dans le bon ordre.

Verrous de mise en production : continuez à traiter ou à attendre d’autres demandes.

Partie 2 : Exécution des demandes et réponse : le réplica principal reçoit un rappel qui indique que l’opération a été appliquée. ReplicateAsync est terminé. Ce rappel indique que l’opération a été reconnue par un quorum des réplicas dans le jeu de réplica. Lorsque le réplica principal reçoit ce rappel, il doit effectuer les actions suivantes :

Recherchez l’opération correspondante indiquée par le LSN long retourné par ReplicateAsync dans la liste en cours d’exécution du service et marquez-la comme « QuorumAck’d ».

À présent, à partir de la première opération de la liste en cours, parcourez la liste et validez localement toutes les opérations QuorumAck’d, terminez les modifications apportées à l’état local et marquez les changements d’état avec leur LSN correspondant, jusqu’à ce que la première opération incomplète se produise. Cela garantit que le classement est conservé (cohérence) et que les opérations sont effectivement appliquées. Cela tire parti des préparations précédentes en matière de durabilité et d’isolation. Remarque : La plupart des services doivent mettre en cache la dernière valeur LSN validée afin que les réponses à ne GetLastCommittedSequenceNumber() nécessitent pas d’interrogation du magasin réel pour le plus grand LSN.

Lorsqu’une opération est validée sur le réplica principal, le réplica principal peut désormais répondre au client qui a lancé l’appel et supprimer l’opération de la liste en cours. Continuez à attendre le prochain rappel d’accusé de réception de quorum.