As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.

Detecção e resolução de conflitos em AWS AppSync

Quando ocorrem gravações simultâneas AWS AppSync, você pode configurar estratégias de detecção e resolução de conflitos para lidar com as atualizações de forma adequada. A detecção de conflitos determina se a mutação está em conflito com o item real gravado na fonte de dados. A Detecção de Conflitos é ativada definindo o valor no conflictDetection campo paraVERSION. SyncConfig

A resolução de conflitos é a ação tomada caso um conflito seja detectado. Isso é determinado definindo o campo Conflict Handler no SyncConfig. Existem três estratégias de resolução de conflitos:

As versões são incrementadas automaticamente AWS AppSync durante as operações de gravação e não devem ser modificadas pelos clientes ou fora de um resolvedor configurado com uma fonte de dados habilitada para versão. Isso muda o comportamento de consistência do sistema e pode ocasionar perda de dados.

Concorrência otimista

A simultaneidade otimista é uma estratégia de resolução de conflitos que AWS AppSync fornece fontes de dados versionadas. Quando o resolvedor de conflitos é definido como Simultaneidade otimista, se uma mutação de entrada é detectada com uma versão diferente da versão real do objeto, o handler de conflitos simplesmente rejeita a solicitação recebida. Dentro da resposta do GraphQL, será fornecido o item existente no servidor que tem a versão mais recente. Espera-se então que o cliente processe esse conflito localmente e repita a mutação com a versão atualizada do item.

Fusões automáticas

O Automerge fornece aos desenvolvedores uma maneira fácil de configurar uma estratégia de resolução de conflitos sem gravar lógica no lado do cliente para mesclar manualmente conflitos incapazes de serem resolvidos com outras estratégias. O Automerge adere a um conjunto de regras rigoroso ao mesclar dados para resolver conflitos. Os princípios do Automerge giram em torno do tipo de dados subjacente do campo GraphQL. Eles são os seguintes:

O Automerge foi projetado para detectar, mesclar e repetir solicitações automaticamente com uma versão atualizada, isentando o cliente da necessidade de mesclar manualmente quaisquer dados conflitantes.

Para mostrar um exemplo de como o Automerge lida com um conflito em um tipo escalar. Usaremos o seguinte registro como nosso ponto de partida.

{
  "id" : 1,
  "name" : "Nadia",
  "jersey" : 5,
  "_version" : 4
}

Agora, uma mutação de entrada pode estar tentando atualizar o item, mas com uma versão mais antiga, uma vez que o cliente ainda não efetuou a sincronização com o servidor. O resultado se parece com:

{
  "id" : 1,
  "name" : "Nadia",
  "jersey" : 55,
  "_version" : 2
}

Observe a versão desatualizada do 2 na solicitação recebida. Durante este fluxo, o Automerge irá mesclar os dados rejeitando a atualização de campo 'jersey' para '55', além de manter o valor em '5', resultando na seguinte imagem do item que está sendo salvo no servidor.

{
  "id" : 1,
  "name" : "Nadia",
  "jersey" : 5,
  "_version" : 5 # version is incremented every time automerge performs a merge that is stored on the server.
}

Considerando o estado do item mostrado acima na versão 5, vamos supor que uma mutação de entrada tente alterar o item com a seguinte imagem:

{
  "id" : 1,
  "name" : "Shaggy",
  "jersey" : 5,
  "interests" : ["breakfast", "lunch", "dinner"] # underlying data type is a Set
  "points": [24, 30, 27] # underlying data type is a List
  "_version" : 3
}

Há três pontos de interesse na mutação de entrada. O nome, um escalar, foi alterado, mas dois novos campos “interesses”, um conjunto, e “pontos”, uma lista, foram adicionados. Neste cenário, um conflito será detectado devido à incompatibilidade de versão. O Automerge adere às suas propriedades e rejeita a alteração de nome por ele ser um escalar e adicionar campos não conflitantes. Isso resulta no item que é salvo no servidor de modo a aparecer da seguinte forma.

{
  "id" : 1,
  "name" : "Nadia",
  "jersey" : 5,
  "interests" : ["breakfast", "lunch", "dinner"] # underlying data type is a Set
  "points": [24, 30, 27] # underlying data type is a List
  "_version" : 6
}

Com a imagem atualizada do item com a versão 6, vamos supor que uma mutação de entrada (com outra incompatibilidade de versão) tente transformar o item para o seguinte:

{
  "id" : 1,
  "name" : "Nadia",
  "jersey" : 5,
  "interests" : ["breakfast", "lunch", "brunch"] # underlying data type is a Set
  "points": [30, 35] # underlying data type is a List
  "_version" : 5
}

Aqui observamos que o campo de entrada para “interesses” tem um valor duplicado que existe no servidor e dois novos valores. Neste caso, como o tipo de dados subjacente é um conjunto, o Automerge combinará os valores existentes no servidor com os da solicitação recebida e eliminará quaisquer duplicatas. Da mesma forma, há um conflito no campo “pontos” onde há um valor duplicado e um novo valor. Entretanto, como o tipo de dados subjacente aqui é uma lista, o Automerge simplesmente acrescentará todos os valores na solicitação de entrada ao final dos valores já existentes no servidor. A imagem mesclada resultante armazenada no servidor aparecerá da seguinte forma:

{
  "id" : 1,
  "name" : "Nadia",
  "jersey" : 5,
  "interests" : ["breakfast", "lunch", "dinner", "brunch"] # underlying data type is a Set
  "points": [24, 30, 27, 30, 35] # underlying data type is a List
  "_version" : 7
}

Agora vamos supor que o item armazenado no servidor aparece da seguinte forma, na versão 8.

{
  "id" : 1,
  "name" : "Nadia",
  "jersey" : 5,
  "interests" : ["breakfast", "lunch", "dinner", "brunch"] # underlying data type is a Set
  "points": [24, 30, 27, 30, 35] # underlying data type is a List
  "stats": {
      "ppg": "35.4",
      "apg": "6.3"
  }
  "_version" : 8
}

Entretanto, uma solicitação de entrada tenta atualizar o item com a imagem a seguir, mais uma vez com uma incompatibilidade de versão:

{
  "id" : 1,
  "name" : "Nadia",
  "stats": {
      "ppg": "25.7",
      "rpg": "6.9"
  }
  "_version" : 3
}

Agora, neste cenário, podemos ver que os campos que já existem no servidor estão ausentes (interesses, pontos, jersey). Além disso, o valor para “ppg” dentro do mapa “stats” está sendo editado, um novo valor “rpg” está sendo adicionado e “apg” é omitido. O Automerge preserva os campos que foram omitidos (observação: se os campos tiverem de ser removidos, será preciso tentar a solicitação novamente com a versão correspondente) para que eles não sejam perdidos. Ele também aplicará as mesmas regras aos campos dentro dos mapas e, portanto, a alteração em “ppg” será rejeitada enquanto “apg” será preservada e “rpg”, um novo campo, será adicionado. Agora, o item resultante armazenado no servidor aparecerá como:

{
  "id" : 1,
  "name" : "Nadia",
  "jersey" : 5,
  "interests" : ["breakfast", "lunch", "dinner", "brunch"] # underlying data type is a Set
  "points": [24, 30, 27, 30, 35] # underlying data type is a List
  "stats": {
      "ppg": "35.4",
      "apg": "6.3",
      "rpg": "6.9"
  }
  "_version" : 9
}

Lambdas

Há várias estratégias de resolução Lambda para escolher:

A solicitação de invocação do Lambda

O AWS AppSync resolvedor do DynamoDB invoca a função Lambda especificada no. LambdaConflictHandlerArn Ele usa o mesmo service-role-arn configurado na fonte de dados. A carga da invocação tem a seguinte estrutura:

{
    "newItem": { ... },
    "existingItem": {... },
    "arguments": { ... },
    "resolver": { ... },
    "identity": { ... }
}

Os campos são definidos da seguinte forma:

Exemplo de carga:

{
    "newItem": {
        "id": "1",
        "author": "Jeff",
        "title": "Foo Bar",
        "rating": 5,
        "comments": ["hello world"],
    },
    "existingItem": {
        "id": "1",
        "author": "Foo",
        "rating": 5,
        "comments": ["old comment"]
    },
    "arguments": {
        "id": "1",
        "author": "Jeff",
        "title": "Foo Bar",
        "comments": ["hello world"]
    },
    "resolver": {
        "tableName": "post-table",
        "awsRegion": "us-west-2",
        "parentType": "Mutation",
        "field": "updatePost"
    },
    "identity": {
         "accountId": "123456789012",
         "sourceIp": "x.x.x.x",
         "username": "AIDAAAAAAAAAAAAAAAAAA",
         "userArn": "arn:aws:iam::123456789012:user/appsync"
    }
}

A resposta de invocação do Lambda

Para resolução de conflitos PutItem e UpdateItem

RESOLVE a mutação. A resposta deve estar no seguinte formato.

{
    "action": "RESOLVE",
    "item": { ... }
}

O campo item representa um objeto que será usado para substituir o item existente na fonte de dados subjacente. A chave primária e os metadados de sincronização serão ignorados se incluídos no item.

REJECT a mutação. A resposta deve estar no seguinte formato.

{
    "action": "REJECT"
}

Para resolução de conflitos DeleteItem

REMOVE o item. A resposta deve estar no seguinte formato.

{
    "action": "REMOVE"
}

REJECT a mutação. A resposta deve estar no seguinte formato.

{
    "action": "REJECT"
}

O exemplo de função do Lambda abaixo verifica quem faz a chamada e o nome do resolvedor. Se for feito porjeffTheAdmin, REMOVE o objeto para o DeletePost resolvedor ou o conflito com RESOLVE o novo item para os resolvedores Update/Put. Se não, a mutação é REJECT.

exports.handler = async (event, context, callback) => {
    console.log("Event: "+ JSON.stringify(event));

    // Business logic goes here.
    var response;
    if ( event.identity.user == "jeffTheAdmin" ) {
        let resolver = event.resolver.field;

        switch(resolver) {
            case "deletePost":
                response = {
                    "action" : "REMOVE"
                }
                break;

            case "updatePost":
            case "createPost":
                response = {
                    "action" : "RESOLVE",
                    "item": event.newItem
                }
                break;
            default:
                response = { "action" : "REJECT" };
        }
    } else {
        response = { "action" : "REJECT" };
    }

    console.log("Response: "+ JSON.stringify(response));
    return response;
}

Erros

Abaixo está uma lista de possíveis erros que podem ocorrer durante um processo de resolução de conflitos:

CloudWatch Registros

Se um AWS AppSync API tiver ativado CloudWatch os registros com as configurações de registro definidas como Registros em nível de campo enabled e em nível de registro para os registros em nível de campo definidas comoALL, então AWS AppSync emitirá informações de detecção e resolução de conflitos para o grupo de registros. Para obter informações sobre o formato das mensagens de log, consulte a documentação de Detecção de conflitos e Registro em log de sincronização.