IStateReplicator.ReplicateAsync Método

Definición

Espacio de nombres:

System.Fabric

Ensamblado:

System.Fabric.dll

Paquete:

Microsoft.ServiceFabric v9.1.1833

Replica los cambios de estado de la réplica principal en las réplicas secundarias y recibe una confirmación de cuórum de que se han aplicado esos cambios de estado.

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)

Parámetros

operationData

OperationData

OperationData que representa el cambio de estado que la réplica principal quiere replicar.

cancellationToken

CancellationToken

Cuórum de escritura de réplicas que se han perdido. Se puede usar para enviar una notificación de que se debe cancelar la operación. Tenga en cuenta que la cancelación es un aviso y que es posible que la operación se complete incluso si se cancela.

sequenceNumber

Int64

Long, el LSN de la operación. Tenga en cuenta que este es el mismo valor que devuelve la tarea. Proporcionarlo como parámetro out es útil para los servicios que desean preparar la escritura local para confirmar cuando finaliza la tarea.

Devoluciones

Task<Int64>

Devuelve Task<TResult> de tipo long, el LSN de la operación.

Excepciones

ArgumentException

Causado por una de las siguientes causas:

E_INVALIDARG se devuelve cuando uno o varios argumentos no son válidos.

FabricTransientException

FabricTransientException es una excepción reintenible. Es causada por uno de los siguientes;

NoWriteQuorum se devuelve cuando el replicador no tiene actualmente quórum de escritura.

ReconfigurationPending se devuelve cuando el replicador tiene una reconfiguración pendiente.

ReplicationQueueFull se devuelve cuando la cola del replicador está llena.

FabricNotPrimaryException

FabricNotPrimaryException es causada por uno de los siguientes;

NotPrimary se devuelve cuando el replicador tiene una reconfiguración pendiente.

FabricObjectClosedException

FabricObjectClosedException es causada por uno de los siguientes;

ObjectClosed se devuelve cuando se ha cerrado el replicador.

OperationCanceledException

OperationCanceledException es causada por uno de los siguientes;

E_ABORT cuando el replicador cancela una operación de replicación en curso.

Comentarios

La replicación en la réplica principal genera los objetos que implementan IOperation que la réplica secundaria obtiene del flujo de replicación a través GetReplicationStream()de , seguido de GetOperationAsync(CancellationToken).

La réplica principal tiene muchas tareas relacionadas con las actualizaciones de estado del proceso. Los pasos siguientes muestran la secuencia general de eventos que una réplica principal debe controlar para replicar y confirmar un cambio.

Parte 1: Control de las solicitudes entrantes: Solicitud de recepción: Write(x): el servicio recibe una solicitud de escritura, x. CheckArguments: el servicio comprueba los argumentos de la solicitud. Esta comprobación ayuda a garantizar la coherencia del estado del servicio.

Comprobar el estado actual: el servicio examina su estado actual para asegurarse de que la operación es válida y puede o debe realizarse. Esta comprobación también ayuda a garantizar la coherencia de los datos. Lo realiza el código de servicio.

Adquirir bloqueos: el servicio debe adquirir los bloqueos necesarios para evitar que se produzcan operaciones adicionales al mismo tiempo. Esta operación ayuda a garantizar el aislamiento y la coherencia.

Operación de intento (opcional): el servicio puede intentar la operación localmente. Este paso reserva y asigna espacio y realiza todos los cálculos necesarios. Este paso incluye todo, pero la confirmación real del resultado. Esta operación mejora la durabilidad de la operación y hace que los errores posteriores son muy improbables.

Fabricación de OperationData: un OperationData objeto es la representación de la escritura(x) que se presentó al servicio. El OperationData objeto contiene el cambio de estado que se va a transferir con confirmación de la réplica principal a las réplicas secundarias. Los datos que coloca el servicio en OperationData definen la actualización atómica que transfiere FabricReplicator a las réplicas secundarias. Tenga en cuenta que la creación del OperationData objeto requiere una o varias matrices de bytes. El propio servicio debe determinar y serializar el cambio en estado y, a continuación, proporcionar este conjunto de bytes al fabricReplicator a través ReplicateAsync(OperationData, CancellationToken, Int64)de . El servicio envía la operación a FabricReplicator y recibe un número de secuencia lógica (LSN) a cambio. El LSN es la identidad de la operación y ayuda tanto al servicio como a Service Fabric a garantizar que las operaciones siempre se aplican en el mismo orden en todas partes. El servicio debe registrar OperationData junto con su LSN en una lista ordenada de operaciones en curso. Esto garantiza que, cuando se completan las operaciones, se pueden aplicar de forma coherente en el orden correcto.

Bloqueos de versión: continúe procesando o esperando más solicitudes.

Parte 2: Finalización de solicitudes y respuestas: la réplica principal recibe una devolución de llamada que indica que se ha aplicado la operación. ReplicateAsync se ha completado. Esta devolución de llamada indica que la operación ha sido reconocida por un cuórum de las réplicas del conjunto de réplicas. Cuando la réplica principal recibe esta devolución de llamada, debe realizar las siguientes acciones:

Busque la operación correspondiente que indica el LSN largo que se devuelve de ReplicateAsync en la lista en curso del servicio y marcadores como "QuorumAck'd".

Ahora, a partir de la primera operación de la lista en curso, recorra la lista y confirme localmente todas las operaciones quorumAck'd, finalice los cambios en el estado local y marque los cambios de estado con su LSN correspondiente, hasta que se encuentre la primera operación incompleta. Esto garantiza que la ordenación se conserve (coherencia) y que las operaciones se apliquen realmente. Esto aprovecha las ventajas de las preparacións de aislamiento y durabilidad anteriores. Nota: La mayoría de los servicios deben almacenar en caché el último valor LSN confirmado para que las respuestas a no GetLastCommittedSequenceNumber() requieran consultar el almacén real para obtener el LSN mayor.

Cuando una operación se confirma correctamente en la réplica principal, la réplica principal ahora puede responder al cliente que inició la llamada y quitar la operación de la lista en curso. Continúe esperando la siguiente devolución de llamada de confirmación de cuórum.