Amazon Web Services 文档中描述的 Amazon Web Services 服务或功能可能因区域而异。要查看适用于中国区域的差异，请参阅 中国的 Amazon Web Services 服务入门 (PDF)。

本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。

冲突检测和同步

版本化数据源

Amazon AppSync 目前支持对 DynamoDB 数据源的版本控制。冲突检测、冲突解决和同步操作需要 Versioned 数据源。对数据源启用版本控制时，Amazon AppSync 将自动执行以下操作：

版本化数据源配置

对 DynamoDB 数据源启用版本控制时，可以指定以下字段：

增量同步表

Amazon AppSync 目前支持使用PutItem、UpdateItem和 DynDeleteItem amoDB 操作对突变进行增量同步日志记录。

当 Amazon AppSync 更改将更改版本化数据源中的项目时，该更改的记录将存储在针对增量更新优化的增量 表中。您可以选择对其他版本数据源使用不同的增量表（例如，每种类型一个，每个域区域一个），或者对您的 API 使用单个 Delta 表。Amazon AppSync 建议不要为多个 API 使用单个 Delta 表，以避免主键冲突。

此表所需的架构如下所示：

配置为与基本 表一起使用的 IAM 角色还必须包含对增量 表进行操作的权限。在此示例中，显示了名为的基表Comments和名为的增量表的权限策略：ChangeLog

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "dynamodb:DeleteItem",
                "dynamodb:GetItem",
                "dynamodb:PutItem",
                "dynamodb:Query",
                "dynamodb:Scan",
                "dynamodb:UpdateItem"
            ],
            "Resource": [
                "arn:aws:dynamodb:us-east-1:000000000000:table/Comments",
                "arn:aws:dynamodb:us-east-1:000000000000:table/Comments/*",
                "arn:aws:dynamodb:us-east-1:000000000000:table/ChangeLog",
                "arn:aws:dynamodb:us-east-1:000000000000:table/ChangeLog/*"
            ]
        }
    ]
}

版本化数据源元数据

Amazon AppSync 代表您管理Versioned数据源上的元数据字段。自行修改这些字段可能会导致应用程序中的错误或数据丢失。这些字段包括：

这些元数据字段将影响此基础数据来源中的项目的总体大小。Amazon AppSync 建议在设计应用程序时，为版本控制的数据源元数据保留 500 字节以上的最大主键存储空间。要在客户端应用程序中使用此元数据，请在您的 GraphQL 类型和更改的选择集中包括 _version、_lastChangedAt 和 _deleted 字段。

冲突检测和解决

当 Amazon AppSync 发生并发写入时，您可以配置冲突检测和冲突解决策略以适当处理更新。冲突检测确定更改是否与数据源中的实际写入项目发生冲突。通过将conflictDetection字段中的值设置为，即可 SyncConfig 启用冲突检测VERSION。

冲突解决是在检测到冲突时执行的操作。这是通过在中设置 “冲突处理器” 字段来确定的 SyncConfig。有三种冲突解决策略：

下文分别详细介绍了这些解决冲突策略。

版本在写入操作 AppSync 期间会自动递增，不应由客户端或配置了启用版本的数据源的解析器外部进行修改。否则会改变系统的一致性行为，并可能导致数据丢失。

乐观并发

乐观并发是 Amazon AppSync 为版本化数据源提供一种冲突解决策略。当冲突解决程序设置为乐观并发时，如果检测到传入的更改具有与对象的实际版本不同的版本，则冲突处理程序将简单地拒绝传入请求。在 GraphQL 响应中，将提供服务器上具有最新版本的现有项目。然后，客户端需要在本地处理此冲突，并使用项目的更新版本重试更改。

Automerge

Automerge 为开发人员提供了配置冲突解决策略的简单方法，而无需编写客户端逻辑来手动合并其他策略无法处理的冲突。Automerge 在合并数据以解决冲突时遵守严格的规则集。Automerge 的原则围绕 GraphQL 字段的底层数据类型。这些原则如下所示：

Automerge 旨在使用更新版本自动检测、合并和重试请求，从而使客户端无需手动合并任何冲突的数据。

为了显示 Automerge 如何处理标量类型上的冲突的示例，我们将使用以下记录作为起点。

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

现在，传入的更改可能正在尝试更新该项目，但使用的是较旧版本，因为客户端尚未与服务器同步。它类似于以下内容：

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

请注意传入请求中的过时版本 2。在此流程中，Automerge 将通过拒绝“球衣”字段更新为“55”来合并数据，并将其值保持在“5”，从而导致下面的项目图像保存在服务器中。

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

鉴于上面显示的具有版本 5 的项目状态，现在假设一个传入的更改尝试使用以下图像改变项目：

{
  "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
}

传入的更改中有三个兴趣点。名称（一个标量）已被更改，但添加了两个新字段“兴趣”（集合）和“分数”（列表）。在这种情况下，将检测到由于版本不匹配而导致的冲突。Automerge 将遵循其属性并拒绝名称更改，因为它是一个标量并添加到非冲突字段。这将导致保存在服务器中的项目显示如下。

{
  "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
}

使用具有版本 6 的项目的更新图像，现在假设传入的更改（版本不匹配）尝试将项目转换为以下内容：

{
  "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
}

在这里，我们观察到“兴趣”的传入字段有一个存在于服务器中的重复值和两个新值。在这种情况下，由于底层数据类型是集合，Automerge 会将服务器中现有的值与传入请求中的值合并，并剔除任何重复项。同样，“分数”字段上也存在冲突，其中有一个重复值和一个新值。但是，由于这里的底层数据类型是列表，Automerge 会简单地将传入请求中的所有值附加到服务器中已存在的值的末尾。存储在服务器上的结果合并图像如下所示：

{
  "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
}

现在，让我们假设存储在服务器中的项目（版本 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
}

但是传入的请求尝试使用以下图像更新该项目，从而再次出现版本不匹配的情况：

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

现在，在这种情况下，我们可以看到服务器中已经存在的字段丢失（兴趣、分数、球衣）。此外，正在编辑映射“统计”中的“ppg”值，添加了一个新值“rpg”，并省略了“apg”。Automerge 保留已省略的字段（注意：如果打算删除字段，则必须使用匹配版本再次尝试请求），以便它们不会丢失。它也会将相同的规则应用于映射中的字段，因此对“ppg”的更改将被拒绝，而“apg”被保留，并添加一个新字段“rpg”。存储在服务器中的结果项目现在将显示为：

{
  "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
}

Lambda

冲突解决选项：

Lambda 调用请求

Amazon AppSync DynamoDB 解析器调用中指定的 Lambda 函数LambdaConflictHandlerArn。它将使用在数据源上配置的相同 service-role-arn。调用的负载具有以下结构：

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

字段定义如下：

有效负载示例：

{
    "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"
    }
}

Lambda 调用响应

对于 PutItem 和 UpdateItem 解决冲突

RESOLVE 更改。响应必须采用以下格式。

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

item 字段表示将用于替换底层数据源中的现有项目的对象。如果在 item 中包含主键和同步元数据，则将被忽略。

REJECT 更改。响应必须采用以下格式。

{
    "action": "REJECT"
}

对于 DeleteItem 冲突解决

REMOVE 项目。响应必须采用以下格式。

{
    "action": "REMOVE"
}

REJECT 更改。响应必须采用以下格式。

{
    "action": "REJECT"
}

下面的示例 Lambda 函数检查谁进行调用以及解析程序名称。如果是由解析器创建的jeffTheAdmin，REMOVE则是 DeletePost解析器的对象或RESOLVE与 Update/Put 解析器的新项目冲突。如果不是，则更改是 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;
}

错误

CloudWatch 日志

如果Amazon AppSync API 启用了 CloudWatch 日志，enabled且日志设置设置设置为字段级日志，字段级日志的日志级别设置为，则Amazon AppSync 会向日志组发送冲突检测和解决信息。ALL有关日志消息格式的信息，请参阅冲突检测和同步日志记录的文档。

同步操作

版本化数据源支持的Sync操作允许您从 DynamoDB 表中检索所有结果，然后仅接收自上次查询（增量更新）以来更改的数据。当 Amazon AppSync 收到 Sync 操作请求时，它会使用请求中指定的字段来确定是否应访问基本 表或增量 表。

Amazon AppSync 将该startedAt字段返回到所有Sync操作的响应映射模板。startedAt 字段是 Sync 操作开始的时刻，以纪元毫秒为单位，您可以在本地存储并在其他请求中使用该值。如果请求中包含分页令牌，则该值将与请求针对第一页结果返回的值相同。

有关 Sync 映射模板格式的信息，请参阅映射模板参考。