IStateReplicator.ReplicateAsync Méthode

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

Retours

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

Exceptions

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.

S’applique à