Recuperar dados de contêiner
Nesse cenário, exploramos a recuperação de dados. Consideramos que os dados serão corrompidos quando o contêiner atinge um estado inválido em que não pode processar outras ações do usuário. O resultado do estado corrompido é o contêiner sendo fechado inesperadamente. Geralmente, é um estado transitório e, após a reabertura, o contêiner pode se comportar conforme o esperado. Em uma situação em que um contêiner não é carregado mesmo após várias tentativas, oferecemos as APIs e os fluxos que você pode usar para recuperar seus dados, conforme descrito abaixo.
Como o Fluid Framework e o Azure Fluid Relay salvam o estado
O Fluid Framework salva periodicamente instantâneos dos dados no contêiner, que resumem todas as alterações feitas nos dados até aquele ponto. Durante o carregamento normal, o snapshot mais recente é recuperado e todas as alterações subsequentes são aplicadas sobre esse estado.
Se o snapshot mais recente ou as alterações subsequentes estiverem corrompidos, talvez o Fluid não consiga carregá-los normalmente. Nesse caso, o Fluid oferece uma coleção de APIs para exibir as versões de snapshot armazenadas e carregá-las em um modo somente exibição sem alterações subsequentes aplicadas. Isso permite que os dados sejam extraídos e, opcionalmente, injetados em um novo contêiner para retomar a colaboração.
APIs de cliente do Azure
APIs para exibir e carregar versões de contêiner
O AzureClient tem os seguintes métodos para dar suporte a esse cenário:
Obter versões de contêiner
getContainerVersions(id, options?)
Recupere uma lista de versões disponíveis que podem ser carregadas.
Parameters:
id: O ID do contêiner. Esse é o mesmo ID usado ao chamargetContainero .options?: Opcionalmente, um objeto options para especificar:maxCount: O número máximo de versões a serem recuperadas. Se houver mais versões disponíveis do que as solicitadas, as versões mais recentes serão recuperadas. Padrão: 5
Returns: Uma promessa que resolve para uma matriz de objetos que representam versões disponíveis (classificadas da mais recente para a mais antiga). Os objetos têm as seguintes propriedades:
id: O ID da versão.- Nota: Isso é diferente do ID do contêiner e faz referência especificamente a uma versão de instantâneo em vez do contêiner.
date: O carimbo de data/hora quando a versão foi gerada.
Exibir a versão de contêiner
viewContainerVersion(id, containerSchema, version, compatibilityMode)
Carregue uma versão específica de um contêiner somente para visualização. Qualquer versão recuperada de getContainerVersions pode ser usada, mas com a finalidade de recuperar dados corrompidos, recomenda-se começar com a versão mais recente e trabalhar para trás para encontrar a versão não corrompida mais recente.
O contêiner é carregado em um estado pausado, o que significa que ele não aplicará as alterações subsequentes aos dados que aconteceram após a geração desse instantâneo. Quando carregados nesse estado, os dados do contêiner podem ser lidos, mas não editados.
Parameters:
id: O ID do contêiner. Esse é o mesmo ID usado ao chamargetContainero .containerSchema: O esquema de contêiner. Esse é o mesmo esquema usado ao chamargetContainero .version: O objeto version que faz referência à versão a ser carregada. O objeto version pode ser recuperado viagetContainerVersions.compatibilityMode: O modo de compatibilidade. Este é o mesmo modo de compatibilidade usado ao chamargetContainero .
Returns: Uma promessa que resolve para um objeto que representa o contêiner carregado com uma única propriedade:
container: O objeto de contêiner. Esse é o mesmo tipo de objeto que o objeto de contêiner retornado pelogetContainer, mas é pausado em seu estado anterior da versão selecionada.
Exemplo
const azureClient = new AzureClient(/* ... */);
const versions = await azureClient.getContainerVersions(id);
// Since the versions are sorted in order from newest to oldest, versions[0] will attempt to load the most recent version.
// If the most recent version is corrupted, we could try again with versions[1] and so on to find the most-recent uncorrupted version.
const { container } = await azureClient.viewContainerVersion(id, containerSchema, versions[0], "2");
// We can now start reading the data from the container.
const someData = container.initialObjects.someSharedMap.get("hello");
// With the data extracted, we can inject it into a new uncorrupted container and attach it to start collaborating again.
const { container: newContainer } = await azureClient.createContainer(containerSchema, "2");
newContainer.initialObjects.someSharedMap.set("hello", someData);
const newId = await newContainer.attach();
Principais observações
Estamos criando um novo Contêiner
Não estamos recuperando (revertendo) contêiner existente. copyContainer nos dará uma nova instância, com os dados sendo copiados do contêiner original. Nesse processo, o contêiner antigo não é excluído.
Novo contêiner é desanexado
O novo contêiner está inicialmente no estado detached. Podemos continuar trabalhando com contêiner desanexado ou anexar imediatamente. Depois de chamar attach, recuperaremos a ID de contêiner exclusiva, representando a instância recém-criada.
Considerações pós-recuperação
Quando se trata de criar casos de uso em torno de cenários pós-recuperação, veja algumas considerações sobre o que o aplicativo pode fazer para que os colaboradores remotos trabalhem no mesmo contêiner novamente.
Se você estiver modelando os dados do aplicativo somente usando contêineres fluidos, o "link" de comunicação será efetivamente interrompido quando o contêiner estiver corrompido. Um exemplo semelhante no mundo real pode ser uma chamada de vídeo em que o autor original compartilhou o link com os participantes e esse link não está mais funcionando. Com essa perspectiva em mente, uma opção é limitar as permissões de recuperação ao autor original e permitir que elas compartilhem um novo link de contêiner da mesma forma que compartilharam o link original, depois de recuperar a cópia do contêiner original.
Como alternativa, se você estiver usando a estrutura fluida apenas para dados transitórios, sempre poderá usar seus próprios dados de origem da verdade e serviços de suporte para gerenciar fluxos de trabalho de recuperação mais autônomos. Por exemplo, vários clientes podem iniciar o processo de recuperação até que o aplicativo tenha uma primeira cópia recuperada. Depois, o aplicativo pode notificar todos os clientes participantes a fazerem a transição para um novo contêiner. Isso pode ser útil, pois qualquer cliente ativo no momento pode desbloquear o grupo participante para continuar a colaboração. Uma consideração aqui são os custos gerados pela redundância.