# 使用 DynamoDB 全局表
全局表基于遍布全球的 Amazon DynamoDB 而构建，可提供完全托管式、多区域和多活动数据库，为大规模的全球应用程序提供高速的本地读写性能。全局表可在您选择的 AWS 区域 自动复制 DynamoDB 表。全局表使用现有的 DynamoDB API，因此无需更改应用程序。使用全局表无需支付任何预付费用，也没有任何承诺，您只需为实际使用的资源付费。
本指南将介绍如何有效使用 DynamoDB 全局表。它提供有关全局表的关键事实，解释该功能的主要使用案例，描述两个一致性模式，介绍您应考虑的三种不同写入模型的分类法，引导您了解可以实施的四种主要请求路由选择，讨论撤离处于活动状态的区域或离线区域的方法，解释如何考虑吞吐能力规划，并提供了部署全局表时需要考虑的事项核对清单。
本指南适用于更广泛的 AWS 多区域部署背景，如 [AWS 多区域基础知识](https://docs.aws.amazon.com/prescriptive-guidance/latest/aws-multi-region-fundamentals/introduction.html)白皮书和 [Data resiliency design patterns with AWS](https://www.youtube.com/watch?v=7IA48SOX20c) 视频中所述。
**Topics**
+ [
## 关于 DynamoDB 全局表设计的关键事实
](#bp-global-table-design.prescriptive-guidance.facts)
+ [
## 关于 MREC 的关键事实
](#bp-global-table-design-MREC-facts)
+ [
## 关于 MRSC 的关键事实
](#bp-global-table-design-MRSC-facts)
+ [
## MREC DynamoDB 全局表使用案例
](#bp-global-table-design.prescriptive-guidance.usecases)
+ [
# 使用 DynamoDB 全局表的写入模式
](bp-global-table-design.prescriptive-guidance.writemodes.md)
+ [
# DynamoDB 中的路由策略
](bp-global-table-design.prescriptive-guidance.request-routing.md)
+ [
# 撤离过程
](bp-global-table-design.prescriptive-guidance.evacuation.md)
+ [
# DynamoDB 全局表的吞吐能力规划
](bp-global-table-design.prescriptive-guidance.throughput.md)
+ [
# DynamoDB 全局表的准备核对清单
](bp-global-table-design.prescriptive-guidance.checklist-and-faq.md)
+ [
## 结论和资源
](#bp-global-table-design.prescriptive-guidance-resources-conclusion)
## 关于 DynamoDB 全局表设计的关键事实
+ 全局表有两个版本：当前版本[全局表版本 2019.11.21（当前版）](GlobalTables.md)（有时称为“V2”）和 [全局表版本 2017.11.29（旧版）](globaltables.V1.md)（有时称为“V1”）。本指南仅关注当前版本。
+ DynamoDB（不含全局表）是一项区域服务，这意味着它具有高可用性，且对基础设施故障具有内在的弹性，包括整个可用区的故障。单区域 DynamoDB 表设计为具有 99.99% 的可用性。有关更多信息，请参阅 [DynamoDB 服务水平协议（SLA）](https://aws.amazon.com/dynamodb/sla/)。
+ DynamoDB 全局表在两个或更多区域间复制其数据。多区域 DynamoDB 表设计为具有 99.999% 的可用性。通过适当的规划，全局表可以帮助创建一个可抵御区域故障的架构。
+ DynamoDB 没有全局端点。所有请求都向区域端点发出，然后该端点访问该区域本地的全局表实例。
+ 对 DynamoDB 的调用不应跨区域进行。最佳实践是，位于某个区域的应用程序应仅直接访问其所在区域的本地 DynamoDB 端点。如果在某个区域（在 DynamoDB 层或在周围堆栈中）内检测到问题，则应将最终用户流量路由到托管在不同区域中的不同应用程序端点。全局表可确保驻留在每个区域的应用程序都能访问相同的数据。
### 一致性模式
创建全局表时，您应配置其一致性模式。全局表支持两种一致性模式：多区域最终一致性（MREC）和多区域强一致性（MRSC），后者于 2025 年 6 月推出。
如果您在创建全局表时未指定一致性模式，则全局表默认为 MREC。全局表不能包含配置了不同一致性模式的副本。创建全局表后，无法更改其一致性模式。
## 关于 MREC 的关键事实
+ 使用 MRSC 的全局表也采用主动-主动复制模型。从 DynamoDB 的角度来看，每个区域中的表在接受读取和写入请求方面具有同等地位。收到写入请求后，本地副本表会在后台将写入操作复制到其他参与远程区域。
+ 项目是单独复制的。在单个事务内更新的项目不能一起复制。
+ 源区域中的每个表分区都会与每个其他分区并行复制其写入操作。远程区域内的写入操作顺序可能与源区域内发生的写入操作顺序不匹配。有关表分区的更多信息，请参阅博客文章 [Scaling DynamoDB: How partitions, hot keys, and split for heat impact performance](https://aws.amazon.com/blogs/database/part-3-scaling-dynamodb-how-partitions-hot-keys-and-split-for-heat-impact-performance/)。
+ 新写入的项目通常会在一秒内传播到所有副本表。附近区域的传播速度往往更快。
+ Amazon CloudWatch 为每个区域对提供一个 `ReplicationLatency` 指标。它的计算方法是查看到达的项目，将它们的到达时间与其初始写入时间进行比较并计算平均值。时间存储在源区域的 CloudWatch 中。查看平均时间和最大时间对于确定平均和最坏情况下的复制滞后非常有用。对于这种延迟，没有 SLA。
+ 如果大约在同一时间（在此 `ReplicationLatency` 时段内）在两个不同的区域更新单个项目，并且第二次写入操作发生在复制第一次写入操作之前，则可能会出现写入冲突。使用 MREC 的全局表会基于写入操作时间戳，采用以最后写入者为准的机制来解决此类冲突。第一个操作“输给了”第二个操作。这些冲突不会记录在 CloudWatch 或 AWS CloudTrail 中。
+ 每个项目都有最后一次写入时间戳，保留为一个私有系统属性。以最后写入者为准方法是通过使用条件写入操作来实现的，条件写入操作要求传入项目的时间戳大于现有项目的时间戳。
+ 全局表会将所有项目复制到所有参与区域。如果您想拥有不同的复制范围，可以创建多个全局表，并为每个表分配不同的参与区域。
+ 即使副本区域处于离线状态或 `ReplicationLatency` 增长，本地区域也会接受写入操作。本地表继续尝试将项目复制到远程表，直到每个项目成功为止。
+ 在极少数情况下，如果某个区域完全离线，则当该区域稍后恢复在线时，将重试所有待处理的出站和入站复制。无需特殊操作即可使表恢复同步。*以最后写入者为准*机制可确保数据最终实现一致性。
+ 您可以随时向 DynamoDB MREC 表添加新区域。DynamoDB 将处理初始同步和持续复制。您也可以删除区域（甚至是原始区域），这将删除该区域中的本地表。
## 关于 MRSC 的关键事实
+ 使用 MRSC 的全局表也采用主动-主动复制模型。从 DynamoDB 的角度来看，每个区域中的表在接受读取和写入请求方面具有同等地位。在写入操作返回成功响应之前，MRSC 全局表副本中的项目更改会**同步**复制到至少一个其他区域。
+ 对任何 MRSC 副本执行的强一致性读取操作始终返回项目的最新版本。条件写入操作始终根据项目的最新版本来评估条件表达式。更新始终根据项目的最新版本进行操作。
+ MRSC 副本上的最终一致性读取操作可能不包括最近在另一个区域发生的更改，甚至可能不包括最近在同一区域发生的更改。
+ 当写入操作尝试修改已在另一个区域中处于正在修改状态的项目时，此操作将失败并引发 `ReplicatedWriteConflictException` 异常。可以重试失败并引发了 `ReplicatedWriteConflictException` 异常的写入操作，如果该项目不再在另一个区域中处于正在修改状态，则写入操作将成功。
+ 使用 MRSC，写入操作和强一致性读取操作的延迟会更高。这些操作需要跨区域通信。此通信会增加延迟，延迟会根据正在访问的区域与加入全局表的最近区域之间的往返延迟而增加。有关更多信息，请参阅 AWS re:Invent 2024 演示：[Multi-Region strong consistency with DynamoDB global tables](https://www.youtube.com/watch?v=R-nTs8ZD8mA)。最终一致性读取操作不会出现额外的延迟。您可以使用开源[测试工具](https://github.com/awslabs/amazon-dynamodb-tools/tree/main/tester)，通过实验计算区域的这些延迟。
+ 项目是单独复制的。使用 MRSC 的全局表不支持事务 API。
+ MRSC 全局表必须部署在恰好三个区域中。您可以将 MRSC 全局表配置为具有三个副本或具有两个副本和一个见证者。见证者是 MRSC 全局表的一个组成部分，其中包含写入全局表副本的最新数据。见证者为完整副本提供了一种可选的替代方案，同时支持 MRSC 的可用性架构。您无法对见证者执行读取或写入操作。见证者不会产生存储或写入成本。见证者位于与两个副本不同的区域内。
+ 要创建 MRSC 全局表，您可以向不包含任何数据的现有 DynamoDB 表添加一个副本和一个见证者，或者添加两个副本。您无法向现有 MRSC 全局表添加其它副本。您无法从 MRSC 全局表中删除单个副本或见证者。您可以从 MRSC 全局表中删除两个副本，或者删除一个副本和一个见证者。第二种场景将剩余的副本转换为单区域 DynamoDB 表。
+ 您可以从 DescribeTable API 的输出中，确定 MRSC 全局表是否配置了见证者以及在哪个区域中配置了见证者。见证者由 DynamoDB 拥有和管理，并且在配置了见证者的区域中，见证者不会出现在您的 AWS 账户中。
+ MRSC 全局表在以下区域集中可用：
+ 美国区域集：美国东部（弗吉尼亚州北部）、美国东部（俄亥俄州）、美国西部（俄勒冈州）
+ 欧洲区域集：欧洲地区（爱尔兰）、欧洲地区（伦敦）、欧洲地区（巴黎）、欧洲地区（法兰克福）
+ 亚太地区区域集：亚太地区（东京）、亚太地区（首尔）和亚太地区（大阪）
+ MRSC 全局表不能跨越区域集。例如，MRSC 全局表不能同时包含来自美国区域集和欧盟区域集的副本。
+ MRSC 全局表不支持生存时间（TTL）。
+ MRSC 全局表不支持本地二级索引（LSI）。
+ CloudWatch Contributor Insights 信息仅针对发生操作的区域进行报告。
+ 只要托管副本或见证者的第二个区域可用于建立仲裁，本地区域就会接受所有读取和写入操作。如果第二个区域不可用，则本地区域只能为最终一致性读取提供服务。
+ 在极少数情况下，如果某个区域完全离线，那么当它稍后重新上线时，会自动赶上进度。在它赶上进度之前，*只有*对正在赶进度的区域执行的写入操作和强一致性读取操作会返回错误，而对其他区域的请求将继续正常执行。对正在赶进度的区域执行的最终一致性读取操作将返回到目前为止已传播到区域中的数据，并且领导节点和本地副本之间具有通常的本地一致性行为。无需特殊操作即可使表恢复同步。
## MREC DynamoDB 全局表使用案例
MREC 全局表提供以下好处：
+ **低延迟读取操作。**将数据的副本放在离最终用户更近的位置，以减少读取操作期间的网络延迟。数据与 `ReplicationLatency` 值一样保持最新。
+ **低延迟写入操作。**您可以写入附近的区域以减少网络延迟和完成写入所需的时间。必须谨慎路由写入流量，以确保没有冲突。[DynamoDB 中的路由策略](bp-global-table-design.prescriptive-guidance.request-routing.md)中详述了路由技术。
+ **无缝的区域迁移。**您可以添加新区域并删除旧区域，以便将部署从一个区域迁移到另一个区域，而且数据层不会出现任何停机时间。
MREC 和 MRSC 全局表都提供了以下好处：
+ **改善了弹性和灾难恢复。**如果某个区域性能下降或完全中断，您可以将其撤离。撤离意味着将发送到该区域的部分或全部请求转走。使用全局表可将 [DynamoDB SLA](https://aws.amazon.com/dynamodb/sla/) 的月度正常运行时间百分比从 99.99% 提高到 99.999%。使用 MREC 支持以秒为单位的恢复点目标（RPO）和恢复时间目标（RTO）。使用 MRSC 支持零 RPO。
例如，Fidelity Investments 在 re:Invent 2022 大会上介绍了他们如何为其订单管理系统使用 DynamoDB 全局表。他们的目标是在大规模处理中，实现本地处理所无法实现的可靠低延迟，同时还在可用区和区域出现故障时保持韧性。
如果您的目标是韧性和灾难恢复，则 MRSC 表具有更高的写入延迟和更高的强一致性读取延迟，而且支持零 RPO。MREC 全局表支持与副本间的复制延迟相等的 RPO，通常为几秒，具体取决于副本所在的区域。
# 使用 DynamoDB 全局表的写入模式
全局表在表级别始终处于主动-主动状态。但是，特别是对于 MREC 表，您可能希望通过控制您路由写入请求的方式来将它们作为主动-被动进行处理。例如，您可能决定将写入请求路由到单个区域，以避免 MREC 表可能发生的潜在写入冲突。
有三种主要的托管式写入模式，如以下三节所述。您应该考虑哪种写入模式适合您的使用案例。此选择会影响您路由请求、撤离区域和处理灾难恢复的方式。后面章节中的指引取决于应用程序的写入模式。
## 写入任何区域模式（非主模式）
如下图所示，*写入任何区域*模式处于完全主动-主动状态，不会对可能发生写入的位置施加限制。任何区域都可以随时接受写入。这是最简单的模式，但只能用于某些类型的应用程序。此模式适用于所有 MRSC 表。当所有写入器都是幂等的，因此可以安全地重复，使得跨区域的并发或重复的写入操作不会发生冲突时，此模式也适用于 MREC 表。例如，当用户更新其联系人数据时。此模式也适用于一种特殊的幂等情况，即仅限追加的数据集，其中所有写入操作都是确定性主键下的唯一插入。最后，在可以接受写入冲突风险时，此模式适用于 MREC。
![\[客户端写入任何区域的工作原理图。\]](http://docs.aws.amazon.com/zh_cn/amazondynamodb/latest/developerguide/images/gt-client-read-write-to-any-region2.png)
*写入任何区域*模式是实现起来最简单的架构。路由更容易，因为任何区域都可以随时成为写入目标。失效转移更容易，因为使用 MRSC 表可以始终同步项目，而且使用 MRSC 表，任何最近的写入都可以对任何辅助区域重播任意次。在可能的情况下，您应该针对这种写入模式进行设计。
例如，一些视频流媒体服务使用全局表来跟踪书签、评论、观看状态标志等。这些部署之所以使用 MREC 表，是因为它们需要分散在世界各地的副本，每个副本都提供低延迟的读取和写入操作。这些部署可以使用*写入任何区域*模式，只要确保每个写入操作都是幂等的即可。如果每次更新（例如设置新的最新时间码、分配新的评论或设置新的观看状态）都会直接分配用户的新状态，且项目的下一个正确值不依赖于当前值，就会出现这种情况。如果将用户的写入请求碰巧路由到不同的区域，则最后一次写入操作将持续存在，全局状态将根据最后一次分配而定。在此模式下，读取操作最终会变得一致，但会因最新的 `ReplicationLatency` 值而延迟。
在另一个例子中，一家金融服务公司使用全局表作为系统的一部分，以持续统计每位客户的借记卡购买情况，从而计算该客户的现金返还奖励。他们希望每位客户都能保留一个 `RunningBalance` 项目。此写入模式本身并不是幂等的，因为随着事务的流入，它们会使用 `ADD` 表达式来修改余额，而新的正确值取决于当前值。通过使用 MRSC 表，他们仍然可以*写入任何区域*，因为每次 `ADD` 调用总是针对项目的最新值进行操作。
第三个示例涉及一家提供在线广告投放服务的公司。该公司已经决定，为了简化*写入任何区域*模式的设计，可以接受较低的数据丢失风险。在投放广告时，公司只有几毫秒的时间检索足够的元数据来确定要展示的广告，然后记录广告展示，以免很快重复展示同一广告。他们使用全局表，为全世界的最终用户实现低延迟的读取操作和低延迟的写入操作。他们在单个项目内记录用户的所有广告展示，并以不断增长的列表形式呈现。他们使用一个项目而不是追加到项目集合中，以便可以在每次写入操作中删除较旧的广告展示，而无需支付删除操作的费用。此写入操作不是幂等的；如果同一个最终用户在大概同一时间看到来自多个区域的广告，则广告展示的一次写入操作可能会覆盖另一次写入操作。风险在于，用户可能会偶尔看到重复的广告。他们认为这是可接受的。
## 写入一个区域（单主模式）
如下图所示，*写入一个区域*模式是主动-被动模式，它将所有表写入操作都路由到单个主动区域。请注意，DynamoDB 没有单一主动区域的概念；DynamoDB 外部的应用程序路由对此进行管理。对于需要避免写入冲突的 MREC 表，*写入一个区域*模式可以很好地确保写入操作一次只流向一个区域。当您想使用条件表达式但由于某种原因无法使用 MRSC 时，或者当您需要执行事务时，此写入模式会有所帮助。除非您知道自己是在针对最新数据执行操作，否则这些表达式是不可能的，因此它们需要将所有写入请求发送到具有最新数据的单个区域。
使用 MRSC 表时，为了方便起见，通常可以选择写入一个区域。例如，这有助于最大限度地减少您在 DynamoDB 之外的基础设施构建。写入模式仍将写入任何区域，因为使用 MRSC，您可以随时安全地写入任何区域，而不必担心会导致 MREC 表选择*写入一个区域*的冲突解决方案。
最终一致性读取可以进入任何副本区域以降低延迟。强一致性读取必须进入单个主区域。
![\[写入一个区域的工作原理示意图。\]](http://docs.aws.amazon.com/zh_cn/amazondynamodb/latest/developerguide/images/gt-client-writes-one-region2.png)
有时需要更改主动区域来应对区域故障。一些用户会定期更改当前主动区域，例如实施“跟随太阳”部署。这会将主动区域放置在活动最多的地理位置附近（通常是白天，因此得名），从而实现最低的读取和写入延迟操作。它还有一个附带好处，那就是每天调用区域不断变化的代码，确保在进行任何灾难恢复之前都经过良好的测试。
被动区域可能会在 DynamoDB 周围保留一组缩小规模的基础设施，而只有当被动区域成为主动区域时，此类基础设施才会建立起来。本指南不涵盖 pilot light 和暖备用设计。有关更多信息，请参阅《[Disaster Recovery (DR) Architecture on AWS, Part III: Pilot Light and Warm Standby](https://aws.amazon.com/blogs/architecture/disaster-recovery-dr-architecture-on-aws-part-iii-pilot-light-and-warm-standby/)》。
在使用全局表进行低延迟的全局分布式读取操作时，使用*写入一个区域*模式效果很好。例如，一家大型社交媒体公司需要在全球每个区域提供相同的参考数据。他们不经常更新数据，但在更新数据时，他们只写入一个区域，以避免任何潜在的写入冲突。任何区域都始终允许进行读取操作。
再举一个例子，考虑一下前面提到的那家实施了每日现金返还计算的金融服务公司。其使用*写入任何区域*模式来计算余额，但使用*写入一个区域*模式来跟踪付款。这项工作需要处理事务，而 MRSC 表不支持这些事务，因此使用单独的 MREC 表和*写入一个区域*模式时效果更好。
## 写入您的区域（混合主模式）
下图所示的*写入您的区域*写入模式适用于 MREC 表。它将不同的数据子集分配给不同的主区域，并且仅允许通过其主区域对项目进行写入操作。此模式为主动-被动模式，但会根据项目分配主动区域。每个区域都是其自己的非重叠数据集的主区域，必须保护写入操作以确保位置正确。
此模式与*写入一个区域*类似，不同之处在于它支持低延迟写入操作，因为与每个最终用户关联的数据可以放在离该用户更近的网络上。此模式还可以在各区域之间更均匀地分布周围的基础设施，并且在失效转移方案中构建基础设施所需的工作量更少，因为所有区域的基础设施都有一部分已经处于主动状态。
![\[有关客户端如何写入到单个区域中的每个项目的工作原理图。\]](http://docs.aws.amazon.com/zh_cn/amazondynamodb/latest/developerguide/images/get-client-writes-each-item-single-region2.png)
您可以通过多种方式确定项目的主区域：
+ **内置函数**：数据的某些方面（例如特殊属性或嵌入在其分区键内的值）可明确其主区域。博客文章 [Use Region pinning to set a home Region for items in an Amazon DynamoDB global table](https://aws.amazon.com/blogs/database/use-region-pinning-to-set-a-home-region-for-items-in-an-amazon-dynamodb-global-table/) 中介绍了此技术。
+ **已协商：**通过某种外部方式协商每个数据集的主区域，例如与维护分配的单独全局服务进行协商。分配可能有一个有限的期限，在此之后需要重新协商。
+ **面向表：**与其创建单个复制全局表，不如创建与复制区域数量相同的全局表。每个表的名称都指示其主区域。在标准操作中，所有数据都写入主区域，而其他区域则保留只读副本。在失效转移期间，另一个区域临时承担对该表的写入职责。
例如，假设您在一家游戏公司工作。您需要为全世界的所有游戏玩家提供低延迟的读取和写入操作。您将每位游戏玩家分配到离其最近的区域。该区域会承担他们所有的读取和写入操作，从而确保很强的写入后读取一致性。但是，如果该游戏玩家外出旅行或其主区域发生中断，则其数据的完整副本将在备用区域中可用，游戏玩家可以分配到不同的主区域。
再举一个例子，假设您在一家视频会议公司工作。每次电话会议的元数据都会分配到一个特定的区域。呼叫者可以使用离他们最近的区域以实现最低延迟。如果出现区域中断，使用全局表可以快速恢复，因为系统可以将呼叫处理转移到已经有数据复制副本的其他区域。
**总结**
+ “写入任何区域”模式适用于 MRSC 表以及对 MREC 表的幂等调用。
+ “写入一个区域”模式适用于对 MREC 表的非幂等调用。
+ “写入您的区域”模式适用于在让客户端写入离其较近的区域非常重要时，对 MREC 表的非幂等调用。
# DynamoDB 中的路由策略
或许全局表部署中最复杂的部分是管理请求路由。请求必须首先从终端用户发送到以某种方式选择和路由的区域。该请求会遇到该区域中的一些服务堆栈，包括一个计算层 [可能由 AWS Lambda 函数支持的负载均衡器、容器或 Amazon Elastic Compute Cloud（Amazon EC2）节点组成]，以及可能包括其他数据库在内的其他服务。该计算层与 DynamoDB 通信。它应该通过使用该区域的本地端点来实现。全局表中的数据会复制到所有其他参与区域，并且每个区域在其 DynamoDB 表周围都有类似的服务堆栈。
全局表为不同区域中的每个堆栈提供具有相同数据的本地副本。如果本地 DynamoDB 表出现问题，您可以考虑在单个区域中设计单个堆栈，并预计会远程调用辅助区域的 DynamoDB 端点。这不是最佳实践。如果一个区域存在由 DynamoDB 引起的问题（或者更有可能是由堆栈中的其他内容或其他依赖于 DynamoDB 的服务造成的），则最好将最终用户路由到另一个区域进行处理，然后使用另一个区域的计算层，该计算层将与其本地 DynamoDB 端点通信。此方法完全绕过了有问题的区域。为了确保韧性，您需要跨多个区域进行复制：计算层以及数据层的复制。
有许多替代技术可以将终端用户请求路由到区域进行处理。最佳选择取决于您的写入模式和失效转移注意事项。本节讨论四个选项：客户端驱动、计算层、Route 53 和 Global Accelerator。
## 客户端驱动的请求路由
如下图所示，使用客户端驱动的请求路由，最终用户客户端（应用程序、使用 JavaScript 的网页或其他客户端）可以跟踪有效的应用程序端点（例如，Amazon API Gateway 端点，而不是字面上的 DynamoDB 端点），并使用自己的嵌入式逻辑来选择要与之通信的区域。该客户端可以根据随机选择、观测到的最低延迟、观测到的最大带宽测量值或本地执行的运行状况检查来进行选择。
![\[向客户选择的目标进行写入的工作原理图。\]](http://docs.aws.amazon.com/zh_cn/amazondynamodb/latest/developerguide/images/gt-routing-is-clients-choice2_v2.png)
客户端驱动的请求路由的优势在于，它可以适应现实世界中的公共互联网流量状况等情况，以便在发现任何性能下降时切换区域。客户端必须知道所有潜在的端点，但启动新的区域端点并不常见。
通过*写入任何区域*模式，客户端可以单方面选择其首选端点。如果客户端对一个区域的访问受到妨碍，则客户端可以路由到另一个端点。
在*写入一个区域*模式下，客户端将需要一种机制来将其写入操作路由到当前主动区域。这可能像凭经验测试哪个区域当前正在接受写入一样基本（注意任何写入拒绝并回退到备用区域），也可能像调用全局协调器来查询当前应用程序状态一样复杂 [可能建立在 Amazon 应用程序恢复控制器（ARC）路由控制之上，该路由控制提供 5 区域仲裁驱动系统来维护全局状态以满足此类需求]。客户端可以决定读取是可以转到任何区域以实现最终一致性，还是必须路由到主动区域以实现强一致性。有关更多信息，请参阅 [Route 53 的工作原理](https://docs.aws.amazon.com/r53recovery/latest/dg/introduction-how-it-works.html)。
在*写入您的区域*模式下，客户端需要确定它正在处理的数据集的主区域。例如，如果客户端对应于一个用户账户，并且每个用户账户都有一个区域作为主区域，则客户端可以从全局登录系统请求相应的端点。
例如，一家通过网络帮助用户管理业务财务的金融服务公司可以使用全局表以及*写入您的区域*模式。每个用户都必须登录中央服务。该服务返回凭证以及将使用这些凭证的区域的端点。凭证在短时间内有效。之后，网页会自动协商新的登录信息，这提供了可能将用户的活动重定向到新区域的机会。
## 计算层请求路由
如下图所示，通过计算层请求路由，在计算层中运行的代码决定是要在本地处理请求，还是将请求传递给在另一个区域运行的其自身的副本。当您使用*写入一个区域*模式时，计算层可能会检测到该区域不是主动区域，并允许本地读取操作，而将所有写入操作转发到另一个区域。此计算层代码必须了解数据拓扑和路由规则，并根据最新设置（用于指定哪些区域对于哪些数据为主动状态）可靠地执行这些规则。区域内的外部软件堆栈不必知道微服务是如何路由读取和写入请求的。在稳健的设计中，接收区域会验证它是否为写入操作的当前主区域。如果不是，则会生成一个错误，表明需要更正全局状态。如果主区域处于更改过程中，则接收区域也可能将写入操作缓冲一段时间。在所有情况下，区域中的计算堆栈仅写入其本地 DynamoDB 端点，但计算堆栈可能会相互通信。
![\[计算层请求路由图。\]](http://docs.aws.amazon.com/zh_cn/amazondynamodb/latest/developerguide/images/gt-compute-layer-routing2.png)
正如 [re:Invent 2022](https://www.youtube.com/watch?v=ilgpzlE7Hds&t=1882s) 大会上所介绍的，Vanguard Group 采用了一个名为 Global Orchestration and Status Tool（GOaST）的系统和一个名为 Global Multi-Region library（GMRlib）的库，来实现此路由过程。它们使用的是“跟随太阳”式单一主区域模式。GOaST 负责维护全局状态，其作用与上一节中讨论的 ARC 路由控制类似。它使用全局表来跟踪哪个区域是主区域，以及何时安排下一次主区域切换。所有读取和写入操作都通过 GMRlib 进行，而 GMRlib 会与 GOaST 进行协调。GMRlib 允许在本地以低延迟执行读取操作。对于写入操作，GMRlib 会检查本地区域是否为当前主区域。如果是，则写入操作将直接完成。否则，GMRlib 会将写入任务转发到主区域中的 GMRlib。该接收库确认它也将自己视为主区域，如果不是，则会引发错误，这表明全局状态存在传播延迟。这种方法不直接写入远程 DynamoDB 端点，从而提供了验证方面的好处。
## Route 53 请求路由
Amazon 应用程序恢复控制器（ARC）是一种域名服务（DNS）技术。使用 Route 53 时，客户端通过查找众所周知的 DNS 域名来请求其端点，Route 53 返回与其认为最合适的区域端点相对应的 IP 地址。此过程如下图所示。Route 53 具有一个很长路由策略列表，用于确定适当的区域。还可以用于失效转移路由，以将流量路由出运行状况检查失败的区域。
![\[计算层请求路由图。\]](http://docs.aws.amazon.com/zh_cn/amazondynamodb/latest/developerguide/images/gt-rt-53-anycast2_v2.png)
通过*写入任何区域*模式，或者与后端的计算层请求路由结合使用，可以向 Route 53 授予完全访问权限，以根据任何复杂的内部规则（例如，最接近网络中的区域、最接近的地理位置中的区域或任何其他选择）返回区域。
通过*写入一个区域*模式，您可以将 Route 53 配置为返回当前主动区域（使用 Route 53 ARC）。如果客户端想要连接到被动区域（例如，用于读取操作），则可以查找不同的 DNS 名称。
**注意**
客户端缓存来自 Route 53 的响应中的 IP 地址，缓存时间由域名上的生存时间（TTL）设置指示。较长的 TTL 可延长所有客户端识别新端点的恢复时间目标（RTO）。60 秒的值通常用于失效转移。并非所有软件都能完全遵守 DNS TTL 到期，且可能存在多个级别的 DNS 缓存，例如在操作系统、虚拟机和应用程序中。
在*写入您的区域*模式下，除非您还使用计算层请求路由，否则最好避开 Route 53。
## Global Accelerator 请求路由
如下图所示，借助 [AWS Global Accelerator](https://aws.amazon.com/global-accelerator/)，客户端可以在 Route 53 中查找众所周知的域名。然而，客户端接收的是路由到最近 AWS 边缘站点的任播静态 IP 地址，而不是获取与区域端点对应的 IP 地址。从该边缘站点开始，所有流量都会路由到私有 AWS 网络上的某个端点（例如负载均衡器或 API Gateway），而该端点所在区域由在 Global Accelerator 中维护的路由规则选择。与基于 Route 53 规则的路由相比，Global Accelerator 请求路由的延迟较低，因为它减少了公共互联网上的流量。此外，由于 Global Accelerator 不依赖于 DNS TTL 到期来更改路由规则，因此它可以更快地调整路由。
![\[使用 Global Accelerator 进行客户端写入的工作原理图。\]](http://docs.aws.amazon.com/zh_cn/amazondynamodb/latest/developerguide/images/gt-routing-gax-excerpt2_v2.png)
通过*写入任何区域*模式，或者在后端与计算层请求路由结合使用，Global Accelerator 可以无缝运行。客户端连接到最近的边缘站点，无需关心哪个区域会收到请求。
使用*写入一个区域*时，Global Accelerator 路由规则必须将请求发送到当前主动区域。您可以使用运行状况检查，人为地报告任何未被全局系统视为主动区域的区域上的故障。与 DNS 一样，如果请求可以来自任何区域，则可以使用备用 DNS 域名来路由读取请求。
在*写入您的区域*模式下，除非您还使用计算层请求路由，否则最好避开 Global Accelerator。
# 撤离过程
撤离区域是指将活动（通常是读取和写入活动，也可能是读取活动）从该区域迁移出去的过程。
## 撤离实时区域
您可能会出于多种原因决定撤离活动区域：作为日常业务活动的一部分（例如，如果您使用“跟随太阳”、“写入一个区域”模式），由于业务决策需要更改当前主动的区域，为了应对 DynamoDB 外部软件堆栈中的故障，或者因为您遇到了一般问题，例如区域内的延迟高于正常水平。
在*写入任何区域*模式下，撤出实时区域很简单。您可以使用任何路由系统将流量路由到备用区域，并让已撤离区域中的写入操作照常复制。
“写入一个区域”模式和“写入您的区域”模式通常与 MREC 表一起使用。因此，在新的主动区域中开始写入操作之前，您必须确保对主动区域的所有写入操作都已完全记录、流处理并全局传播，以确保将来的写入操作是针对最新版本的数据进行处理的。
假设区域 A 处于主动状态，区域 B 处于被动状态（无论是对于整个表，还是对于以区域 A 为主区域的项目）。执行撤离的典型机制是暂停对 A 的写入操作，等待足够长的时间让这些操作完全传播到 B，更新架构堆栈以识别 B 处于主动状态，然后恢复对 B 的写入操作。没有任何指标可以绝对肯定地表明区域 A 已将其数据完全复制到区域 B。如果区域 A 运行状况正常，暂停对区域 A 的写入操作并等待 `ReplicationLatency` 指标的最近最大值的 10 倍，通常足以确定复制完成。如果区域 A 运行状况不佳且显示延迟增加的其他区域，则应为等待时间选择更大的倍数。
## 撤离离线区域
有一个特殊情况需要考虑：如果区域 A 在没有通知的情况下完全离线，会怎样？ 这种情况发生的可能性极低，但仍应考虑在内。
撤离离线 MRSC 表
如果 MRSC 表发生这种情况，您无需执行任何特殊操作。MRSC 表支持恢复点目标（RPO）为零。对离线区域中的 MRSC 表进行的所有成功写入操作都将在所有其他区域表中可用，因此即使区域在未发出通知的情况下完全离线，也不会出现数据缺失的情况。业务可以继续使用位于其他区域的副本。
撤离离线 MREC 表
如果 MREC 表发生这种情况，则区域 A 中尚未传播的任何写入操作都将保留，并在区域 A 恢复在线后进行传播。写入操作不会丢失，但它们的传播会被无限期延迟。
在这种情况下，如何继续操作将由应用程序决定。为了实现业务连续性，写入操作可能需要继续指向新的主区域 B。但是，如果区域 B 中的某个项目收到更新，而针对该项目的写入操作有来自区域 A 的挂起传播，则在*以最后写入者为准*模型下，该传播将被抑制。区域 B 中的任何更新都可能抑制传入的写入请求。
在*写入任何区域*模式下，可以在区域 B 中继续读取和写入操作，同时相信区域 A 中的项目最终会传播到区域 B，并认识到在区域 A 恢复在线之前可能会丢失项目。如果可能，例如对于幂等的写入操作，您应考虑重播新近的写入流量（例如，使用上游事件源），以填补任何可能缺失的写入操作的空白，并让以最后写入者为准冲突解决方案来抑制传入写入操作的最终传播。
对于其他写入模式，您必须考虑在多大程度上可以继续工作，而对工作环境的看法稍微过时。在区域 A 恢复在线之前，将丢失一些持续时间很短的写入操作（由 `ReplicationLatency` 跟踪）。业务能否向前推进？ 在某些使用案例中可以向前推进，但在另一些使用案例中，如果没有额外的缓解机制，则可能不行。
例如，假设即使某个区域完全中断服务，您也必须保持可用的抵扣金余额，不得中断。您可以将余额拆分为两个不同的项目，一个位于主区域 A 中，另一个位于区域 B 中，每个项目从可用余额的一半开始。这将使用*写入您的区域*模式。在每个区域中处理的事务性更新将写入余额的本地副本。如果区域 A 变为完全离线，则仍然可以在区域 B 中继续进行事务处理，写入操作将仅限于区域 B 中持有的余额部分。当余额变低或必须重新计算信贷余额时，像这样拆分余额会带来复杂性，但它确实提供了一个安全业务恢复的示例，即使存在不确定的待处理写入操作。
再举一个例子，假设您正在捕获 Web 表单数据。您可以使用[乐观并发控制（OCC）](DynamoDBMapper.OptimisticLocking.md)为数据项目分配版本，并将最新版本作为隐藏字段嵌入到 Web 表单中。在每次提交时，只有当数据库中的版本仍然与构建表单所依据的版本相匹配时，写入操作才会成功。如果版本不匹配，则可以根据数据库中的当前版本刷新（或谨慎合并）Web 表单，然后用户可以再次继续。OCC 模型通常可以防止其他客户端覆盖并生成新版本的数据，但它也可以在失效转移期间提供帮助，此时客户端可能会遇到更旧版本的数据。假设您使用时间戳作为版本。表单最初是在 12:00 针对区域 A 构建的，但是（失效转移后）尝试写入区域 B 并注意到数据库中的最新版本是 11:59。在这种情况下，客户端可以等待 12:00 版本传播到区域 B，然后在该版本之上进行写入；也可以在 11:59 上构建并创建新的 12:01 版本（写入后，该版本将在区域 A 恢复后抑制传入版本）。
第三个例子是，一家金融服务公司在 DynamoDB 数据库中保存有关客户账户及其金融交易的数据。如果区域 A 完全中断，他们希望确保与其账户相关的任何写入活动在区域 B 中完全可用，或者希望将他们的账户作为已知的部分账户进行隔离，直到区域 A 恢复在线。他们没有暂停所有业务，而是决定只对他们确定有未传播交易的一小部分账户暂停业务。为了实现这一点，他们使用了第三个区域，我们称为区域 C。在他们处理区域 A 中的任何写入操作之前，他们在区域 C 中简要地汇总了那些待处理的操作（例如，一个账户的新交易数量）。这个摘要足以让区域 B 确定其视图是否完全是最新的。从在区域 C 中写入操作，到区域 A 接受写入操作并且区域 B 收到写入操作之前，此操作实际上锁定了该账户。除非作为失效转移过程的一部分，否则不会使用区域 C 中的数据，之后，区域 B 可以将其数据与区域 C 进行交叉核对，以检查其账户是否已过期。在区域 A 恢复将部分数据传播到区域 B 之前，这些账户将标记为已隔离。如果区域 C 出现故障，则可以启动一个新的区域 D 以供使用。区域 C 中的数据非常短暂，几分钟后，区域 D 将具有足够新的动态写入操作记录，这将非常有用。如果区域 B 出现故障，区域 A 可以继续接受与区域 C 合作的写入请求。这家公司愿意接受延迟更高的写入（写入到两个区域：C，然后是 A），并且很幸运有了一个可以简洁汇总账户状态的数据模型。
# DynamoDB 全局表的吞吐能力规划
将流量从一个区域迁移到另一个区域时，需要仔细考虑容量方面的 DynamoDB 表设置。
以下是管理写入容量的一些注意事项：
+ 全局表必须处于按需模式，或在启用自动扩缩的情况下进行预调配。
+ 如果使用自动扩缩进行预调配，则会跨区域复制写入设置（最小、最大和目标利用率）。尽管自动扩缩设置已同步，但实际的预调配写入容量可能会在区域间独立浮动。
+ 您可能会看到不同预调配写入容量的原因之一是 TTL 功能。当您在 DynamoDB 中启用 TTL 时，您可以指定一个属性名称，其值表示项目的过期时间，采用 Unix 纪元时间格式，单位为秒。在该时间之后，DynamoDB 可以删除该项目而不会产生写入成本。使用全局表，您可以在任何区域中配置 TTL，并且该设置会自动复制到与全局表关联的其他区域。当某个项目符合通过 TTL 规则删除的条件时，该工作可以在任何区域中完成。执行删除操作时不消耗源表上的写入单位，但是副本表将获得该删除操作的复制写入，并将产生复制写入单位成本。MRSC 表不支持 TTL。
+ 如果您使用自动扩缩，请确保最大预调配写入容量设置足够高，足以处理所有写入操作以及所有潜在的 TTL 删除操作。自动扩缩根据每个区域的写入消耗量调整每个区域。按需表没有最大预调配写入容量设置，但*表级别的最大写入吞吐量限制*指定了按需表将允许的最大持续写入容量。原定设置限制为 40000，但可以调整。我们建议您将其设置得足够高，以处理按需表可能需要的所有写入操作（包括 TTL 写入操作）。设置全局表时，此值在所有参与区域间必须相同。
以下是管理读取容量的一些注意事项：
+ 允许不同区域之间的读取容量管理设置有所不同，因为假设不同的区域可能有独立的读取模式。当您首先向表添加全局副本时，将传播源区域的容量。创建后，您可以调整读取容量设置，这些新设置不会传输到另一端。
+ 使用 DynamoDB Auto Scaling 时，请确保最大预调配读取容量设置足够高，足以处理所有区域的所有读取操作。在标准操作期间，读取容量可能会分布在各个区域之间，但在失效转移期间，表应该能够自动适应增加的读取工作负载。按需表没有最大预调配读取容量设置，但*表级别的最大读取吞吐量限制*指定了按需表将允许的最大持续读取容量。原定设置限制为 40000，但可以调整。我们建议您将其设置得足够高，以处理该表可能需要的所有读取操作（当所有读取操作都路由到此单个区域时）。
+ 如果一个区域中的表通常不会接收读取流量，但在失效转移后可能必须吸收大量读取流量，则可以预调配该表的容量以接受更高水平的读取流量。
无论您是否使用 Route 53 来路由请求，ARC 都有[就绪检查](https://docs.aws.amazon.com/r53recovery/latest/dg/recovery-readiness.rules-resources.html)功能，这对于确认 DynamoDB 区域是否具有相似的表设置和账户限额非常有用。这些就绪检查功能还有助于调整账户级别的限额以确保它们匹配。
# DynamoDB 全局表的准备核对清单
在部署全局表时，请使用下面的决策和任务核对清单。
+ 确定您的使用案例是否从 MRSC 或 MREC 一致性模式中受益更多。即使延迟较高以及存在其他方面的不足，您是否也需要强一致性？
+ 确定全局表应涉及多少个区域以及哪些区域。如果您计划使用 MRSC，请决定希望第三个区域成为副本区域还是见证区域。
+ 确定应用程序的写入模式。这与一致性模式不同。有关更多信息，请参阅 [使用 DynamoDB 全局表的写入模式](bp-global-table-design.prescriptive-guidance.writemodes.md)。
+ 根据写入模式规划您的[DynamoDB 中的路由策略](bp-global-table-design.prescriptive-guidance.request-routing.md)策略。
+ 根据您的一致性模式、写入模式和路由策略，定义[ 撤离过程 使用全局表撤离区域 撤离区域是指将活动（通常是读取和写入活动，也可能是读取活动）从该区域迁移出去的过程。 撤离实时区域实时区域 撤离实时区域 您可能会出于多种原因决定撤离活动区域：作为日常业务活动的一部分（例如，如果您使用“跟随太阳”、“写入一个区域”模式），由于业务决策需要更改当前主动的区域，为了应对 DynamoDB 外部软件堆栈中的故障，或者因为您遇到了一般问题，例如区域内的延迟高于正常水平。 在*写入任何区域*模式下，撤出实时区域很简单。您可以使用任何路由系统将流量路由到备用区域，并让已撤离区域中的写入操作照常复制。 “写入一个区域”模式和“写入您的区域”模式通常与 MREC 表一起使用。因此，在新的主动区域中开始写入操作之前，您必须确保对主动区域的所有写入操作都已完全记录、流处理并全局传播，以确保将来的写入操作是针对最新版本的数据进行处理的。 假设区域 A 处于主动状态，区域 B 处于被动状态（无论是对于整个表，还是对于以区域 A 为主区域的项目）。执行撤离的典型机制是暂停对 A 的写入操作，等待足够长的时间让这些操作完全传播到 B，更新架构堆栈以识别 B 处于主动状态，然后恢复对 B 的写入操作。没有任何指标可以绝对肯定地表明区域 A 已将其数据完全复制到区域 B。如果区域 A 运行状况正常，暂停对区域 A 的写入操作并等待 `ReplicationLatency` 指标的最近最大值的 10 倍，通常足以确定复制完成。如果区域 A 运行状况不佳且显示延迟增加的其他区域，则应为等待时间选择更大的倍数。 撤离离线区域离线区域 撤离离线区域 有一个特殊情况需要考虑：如果区域 A 在没有通知的情况下完全离线，会怎样？ 这种情况发生的可能性极低，但仍应考虑在内。
撤离离线 MRSC 表
如果 MRSC 表发生这种情况，您无需执行任何特殊操作。MRSC 表支持恢复点目标（RPO）为零。对离线区域中的 MRSC 表进行的所有成功写入操作都将在所有其他区域表中可用，因此即使区域在未发出通知的情况下完全离线，也不会出现数据缺失的情况。业务可以继续使用位于其他区域的副本。
撤离离线 MREC 表
如果 MREC 表发生这种情况，则区域 A 中尚未传播的任何写入操作都将保留，并在区域 A 恢复在线后进行传播。写入操作不会丢失，但它们的传播会被无限期延迟。
在这种情况下，如何继续操作将由应用程序决定。为了实现业务连续性，写入操作可能需要继续指向新的主区域 B。但是，如果区域 B 中的某个项目收到更新，而针对该项目的写入操作有来自区域 A 的挂起传播，则在*以最后写入者为准*模型下，该传播将被抑制。区域 B 中的任何更新都可能抑制传入的写入请求。
在*写入任何区域*模式下，可以在区域 B 中继续读取和写入操作，同时相信区域 A 中的项目最终会传播到区域 B，并认识到在区域 A 恢复在线之前可能会丢失项目。如果可能，例如对于幂等的写入操作，您应考虑重播新近的写入流量（例如，使用上游事件源），以填补任何可能缺失的写入操作的空白，并让以最后写入者为准冲突解决方案来抑制传入写入操作的最终传播。
对于其他写入模式，您必须考虑在多大程度上可以继续工作，而对工作环境的看法稍微过时。在区域 A 恢复在线之前，将丢失一些持续时间很短的写入操作（由 `ReplicationLatency` 跟踪）。业务能否向前推进？ 在某些使用案例中可以向前推进，但在另一些使用案例中，如果没有额外的缓解机制，则可能不行。
例如，假设即使某个区域完全中断服务，您也必须保持可用的抵扣金余额，不得中断。您可以将余额拆分为两个不同的项目，一个位于主区域 A 中，另一个位于区域 B 中，每个项目从可用余额的一半开始。这将使用*写入您的区域*模式。在每个区域中处理的事务性更新将写入余额的本地副本。如果区域 A 变为完全离线，则仍然可以在区域 B 中继续进行事务处理，写入操作将仅限于区域 B 中持有的余额部分。当余额变低或必须重新计算信贷余额时，像这样拆分余额会带来复杂性，但它确实提供了一个安全业务恢复的示例，即使存在不确定的待处理写入操作。
再举一个例子，假设您正在捕获 Web 表单数据。您可以使用[乐观并发控制（OCC）](DynamoDBMapper.OptimisticLocking.md)为数据项目分配版本，并将最新版本作为隐藏字段嵌入到 Web 表单中。在每次提交时，只有当数据库中的版本仍然与构建表单所依据的版本相匹配时，写入操作才会成功。如果版本不匹配，则可以根据数据库中的当前版本刷新（或谨慎合并）Web 表单，然后用户可以再次继续。OCC 模型通常可以防止其他客户端覆盖并生成新版本的数据，但它也可以在失效转移期间提供帮助，此时客户端可能会遇到更旧版本的数据。假设您使用时间戳作为版本。表单最初是在 12:00 针对区域 A 构建的，但是（失效转移后）尝试写入区域 B 并注意到数据库中的最新版本是 11:59。在这种情况下，客户端可以等待 12:00 版本传播到区域 B，然后在该版本之上进行写入；也可以在 11:59 上构建并创建新的 12:01 版本（写入后，该版本将在区域 A 恢复后抑制传入版本）。
第三个例子是，一家金融服务公司在 DynamoDB 数据库中保存有关客户账户及其金融交易的数据。如果区域 A 完全中断，他们希望确保与其账户相关的任何写入活动在区域 B 中完全可用，或者希望将他们的账户作为已知的部分账户进行隔离，直到区域 A 恢复在线。他们没有暂停所有业务，而是决定只对他们确定有未传播交易的一小部分账户暂停业务。为了实现这一点，他们使用了第三个区域，我们称为区域 C。在他们处理区域 A 中的任何写入操作之前，他们在区域 C 中简要地汇总了那些待处理的操作（例如，一个账户的新交易数量）。这个摘要足以让区域 B 确定其视图是否完全是最新的。从在区域 C 中写入操作，到区域 A 接受写入操作并且区域 B 收到写入操作之前，此操作实际上锁定了该账户。除非作为失效转移过程的一部分，否则不会使用区域 C 中的数据，之后，区域 B 可以将其数据与区域 C 进行交叉核对，以检查其账户是否已过期。在区域 A 恢复将部分数据传播到区域 B 之前，这些账户将标记为已隔离。如果区域 C 出现故障，则可以启动一个新的区域 D 以供使用。区域 C 中的数据非常短暂，几分钟后，区域 D 将具有足够新的动态写入操作记录，这将非常有用。如果区域 B 出现故障，区域 A 可以继续接受与区域 C 合作的写入请求。这家公司愿意接受延迟更高的写入（写入到两个区域：C，然后是 A），并且很幸运有了一个可以简洁汇总账户状态的数据模型。 ](bp-global-table-design.prescriptive-guidance.evacuation.md#bp-global-table-design.prescriptive-guidance.evacuation.title)[撤离过程](bp-global-table-design.prescriptive-guidance.evacuation.md)。
+ 捕获有关每个区域的运行状况、延迟和错误的指标。有关 DynamoDB 指标的列表，请参阅 AWS 博客文章[监控 Amazon DynamoDB 的操作感知](https://aws.amazon.com/blogs/database/monitoring-amazon-dynamodb-for-operational-awareness/)，以获取需要观察的指标列表。您还应该使用 [Synthetics Canary](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html)（合成金丝雀，旨在检测故障的人工请求，以煤矿中的金丝雀命名），以及实时观察客户流量。并非所有问题都会出现在 DynamoDB 指标中。
+ 如果您使用的是 MREC，请在 `ReplicationLatency` 中为任何持续增长设置警报。增加可能表示意外配置错误，即全局表在不同区域中具有不同的写入设置，这会导致复制请求失败和延迟增加。这也可能表明存在区域中断。一个[很好的例子](https://aws.amazon.com/blogs/database/monitoring-amazon-dynamodb-for-operational-awareness/)是，如果最近的平均值超过 180000 毫秒，则生成警报。您可能还会观察到 `ReplicationLatency` 降至 0，这表示复制已停止。
+ 为每个全局表分配足够的最大读取和写入设置。
+ 提前确定撤离某个区域的原因。如果决定涉及人为判断，请记录所有考虑因素。这项工作应该事先仔细完成，而不是在压力下匆匆了事。
+ 为撤离某个区域时必须采取的每项措施制定一份运行手册。通常，全局表所涉及的工作非常少，但是移动堆栈的其余部分可能很复杂。
**注意**
使用失效转移过程，最佳做法是仅依赖数据面板操作，而不依赖控制面板操作，因为在区域故障期间，某些控制面板操作可能会降级。
有关更多信息，请参阅 AWS 博客文章[使用 Amazon DynamoDB 全局表构建弹性应用程序：第 4 部分](https://aws.amazon.com/blogs/database/part-4-build-resilient-applications-with-amazon-dynamodb-global-tables/)。
+ 定期测试运行手册的各个方面，包括区域撤离。未经测试的运行手册是不可靠的。
+ 考虑使用 [AWS Resilience Hub](https://docs.aws.amazon.com/resilience-hub/latest/userguide/what-is.html)来评估整个应用程序（包括全局表）的韧性。通过韧性监测中心的控制面板，您可以全面查看应用程序产品组合的整体弹性状态。
+ 考虑使用 ARC 就绪检查功能来评估应用程序的当前配置，并跟踪与最佳实践的任何偏差。
+ 在编写用于 Route 53 或 Global Accelerator 的运行状况检查时，进行一组覆盖整个数据库流的调用。如果您将检查限制为仅确认 DynamoDB 端点已启动，则无法涵盖许多故障模式，例如 AWS Identity and Access Management（IAM）配置错误、代码部署问题、DynamoDB 外部的堆栈故障、高于平均读取或写入延迟等。
## 有关部署全局表的常见问题解答（FAQ）
**全局表的定价是多少？**
+ 对传统 DynamoDB 表的写入操作按写入容量单位（WCU，用于预调配表）或写入请求单位（WRU，用于按需表）定价。如果您写入一个 5KB 项目，则会产生 5 个单位的费用。对全局表的写入按复制写入容量单位（rWCU，用于预调配表）或复制写入请求单位（rWRU，用于按需表）定价。rWCU 和 rWRU 的价格与 WGU 和 WRU 的价格相同。
+ 在其中直接写入或通过复制写入项目的每个区域都会产生 rWCU 和 rWRU 费用。跨区域数据传输费用适用。
+ 写入全局二级索引（GSI）被视为本地写入操作，使用常规写入单位。
+ 目前 rWCU 或 rWRU 没有可用的预留容量。对于 GSI 消耗写入单位的表，为 WCU 购买预留容量可能仍有好处。
+ 当您将新区域添加到全局表时，DynamoDB 会自动引导新区域，并根据表的大小（GB）向您收取费用，就像表还原一样。还会收取跨区域数据传输费用。
**全局表支持哪些区域？**
[全局表版本 2019.11.21（当前）](GlobalTables.md)对于 MREC 表支持所有 AWS 区域，对于 MRSC 表支持以下区域集：
+ 美国区域集：美国东部（弗吉尼亚州北部）、美国东部（俄亥俄州）、美国西部（俄勒冈州）
+ 欧洲区域集：欧洲地区（爱尔兰）、欧洲地区（伦敦）、欧洲地区（巴黎）、欧洲地区（法兰克福）
+ 亚太地区区域集：亚太地区（东京）、亚太地区（首尔）和亚太地区（大阪）
**如何使用全局表处理 GSI？**
在[全局表版本 2019.11.21（当前版）](GlobalTables.md)中，当您在一个区域中创建 GSI 时，它会在其它参与区域中自动创建并自动回填。
**如何停止复制全局表？**
+ 您可以像删除任何其他表一样删除副本表。删除全局表将停止复制到该区域，并删除保留在该区域中的表副本。但是，不能在将表的副本保留为独立实体时停止复制，也不能暂停复制。
+ MRSC 表必须部署在恰好三个区域中。要删除副本，您必须删除所有副本和见证者，以使 MRSC 表成为本地表。
**DynamoDB Streams 如何与全局表交互？**
+ 每个全局表都基于其所有写入操作生成一个独立的流，而无论这些写入是从何处开始的。您可以选择在一个区域或在所有区域中（独立）使用 DynamoDB 流。如果您想要处理本地而不是复制的写入操作，则可以向每个项目添加您自己的区域属性，以确定写入区域。然后，您可以使用 Lambda 事件筛选条件，以便只调用 Lambda 函数来处理本地区域中的写入操作。这有助于执行插入和更新操作，但不能执行删除操作。
+ 配置为多区域最终一致性的全局表（MREC 表）可通过从副本表上的 DynamoDB 流读取这些更改，并将该更改应用于所有其他副本表，从而复制更改。因此，默认情况下，对 MREC 全局表中的所有副本都启用了 DynamoDB，并且无法在这些副本上禁用。MREC 复制过程可能会在短时间内将多项更改合并到单个复制写入操作中。因此，每个副本的流均可能包含略有不同的记录。MREC 副本上的 DynamoDB Streams 记录始终按每个项目排序，但项目间的排序可能在副本之间有所不同。
+ 配置为多区域强一致性的全局表（MRSC 表）不使用 DynamoDB Streams 进行复制，因此默认情况下不在 MRSC 副本上启用此功能。您可以在 MRSC 副本上启用 DynamoDB Streams。MRSC 副本上的 DynamoDB Streams 记录对于每个副本都是相同的，并且始终按项目排序，但项目之间的排序在副本之间可能有所不同。
**全局表如何处理事务？**
+ 对 MRSC 表的事务操作会生成错误。
+ 对 MREC 表的事务操作，仅在最初发生写入操作的区域内提供原子性、一致性、隔离性和持久性（ACID）保证。全局表中不支持跨区域的事务。例如，如果您有一个 MREC 全局表，该表在美国东部（俄亥俄州）和美国西部（俄勒冈州）区域中具有副本，并且在美国东部（俄亥俄州）区域中执行 `TransactWriteItems` 操作，则在复制更改时，可能会在美国西部（俄勒冈州）区域观察到部分完成的事务。更改仅在源区域中提交后才复制到其他区域。
**全局表如何与 DynamoDB Accelerator 缓存（DAX）交互？**
全局表通过直接更新 DynamoDB 绕过 DAX，因此 DAX 并不知道它保存的是陈旧数据。DAX 缓存只有在缓存的 TTL 过期时才会刷新。
**表上的标签会传播吗？**
不，标签不会自动传播。
**我应该备份所有区域中的表，还是只备份一个区域中的表？**
答案取决于备份的目的。
+ 如果您想确保数据的耐久性，DynamoDB 已经提供了这种保护措施。该服务可确保耐久性。
+ 如果您想保留历史记录的快照（例如，为了符合法规要求），备份一个区域中的表就应该足够了。您可以使用 将备份复制到其他区域AWS Backup
+ 如果您想恢复错误删除或修改的数据，请在一个区域中使用 [DynamoDB 时间点故障恢复（PITR）](PointInTimeRecovery_Howitworks.md)。
**如何使用 CloudFormation 部署全局表？**
+ CloudFormation 将 DynamoDB 表和全局表表示为两个独立的资源：`AWS::DynamoDB::Table` 和 `AWS::DynamoDB::GlobalTable`。一种方法是使用 `GlobalTable` 构造来创建所有可能成为全局表的表，最初将其保留为独立的表，然后在以后需要时再添加区域。
+ 在 CloudFormation 中，每个全局表都由单个区域中的单个堆栈控制，而与副本的数量无关。部署模板时，CloudFormation 将创建和更新所有副本（作为单个堆栈操作的一部分）。您不应在多个区域中部署相同的 [AWS::DynamoDB::GlobalTable](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-dynamodb-globaltable.html) 资源。这样做会导致错误，不受支持。如果在多个区域中部署应用程序模板，则可以使用条件在单个区域中创建 `AWS::DynamoDB::GlobalTable` 资源。或者，您可以选择在独立于应用程序堆栈的堆栈中定义 `AWS::DynamoDB::GlobalTable` 资源，并确保仅将该资源部署到单个区域。
+ 如果您有一个常规表，并且想要将其转换为全局表，同时保持它由 CloudFormation 管理，则将删除策略设置为 `Retain`，从堆栈中删除该表，在控制台中将该表转换为全局表，然后将该全局表作为新资源导入到堆栈中。有关更多信息，请参阅 [AWS GitHub 存储库](https://github.com/aws-samples/amazon-dynamodb-table-to-global-table-cdk)。
+ 目前不支持跨账户复制。
## 结论和资源
DynamoDB 全局表的控件很少，但仍然需要仔细考虑。您必须确定您的写入模式、路由模型和撤离过程。您必须针对每个区域对应用程序进行检测，并准备好调整路由或执行撤离，以维护全局运行状况。回报是拥有一个全球分布的数据集，该数据集可以实现低延迟的读取和写入操作，可用性设计为 99.999%。
有关 DynamoDB 全局表的更多信息，请参阅以下资源：
+ [DynamoDB 文档](https://docs.aws.amazon.com/dynamodb/)
+ [Amazon Application Recovery Controller](https://aws.amazon.com/application-recovery-controller/)
+ [ARC 中的就绪检查](https://docs.aws.amazon.com/r53recovery/latest/dg/recovery-readiness.html)（AWS 文档）
+ [Route 53 路由策略](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/routing-policy.html)
+ [AWS Global Accelerator](https://aws.amazon.com/global-accelerator/)
+ [DynamoDB 服务水平协议](https://aws.amazon.com/dynamodb/sla/)
+ [AWS 多区域基础知识](https://docs.aws.amazon.com/prescriptive-guidance/latest/aws-multi-region-fundamentals/introduction.html)（AWS 白皮书）
+ [Data resiliency design patterns with AWS](https://www.youtube.com/watch?v=7IA48SOX20c)（AWS re:Invent 2022 演示）
+ [How Fidelity Investments and Reltio modernized with Amazon DynamoDB](https://www.youtube.com/watch?v=QUpV5MDu4Ys&t=706s)（AWS re:Invent 2022 演示）
+ [Multi-Region design patterns and best practices](https://www.youtube.com/watch?v=ilgpzlE7Hds&t=1882s)（AWS re:Invent 2022 演示）
+ [Disaster Recovery (DR) Architecture on AWS, Part III: Pilot Light and Warm Standby](https://aws.amazon.com/blogs/architecture/disaster-recovery-dr-architecture-on-aws-part-iii-pilot-light-and-warm-standby/)（AWS 博客文章）
+ [Use Region pinning to set a home Region for items in an Amazon DynamoDB global table](https://aws.amazon.com/blogs/database/use-region-pinning-to-set-a-home-region-for-items-in-an-amazon-dynamodb-global-table/)（AWS 博客文章）
+ [Monitoring Amazon DynamoDB for operational awareness](https://aws.amazon.com/blogs/database/monitoring-amazon-dynamodb-for-operational-awareness/)（AWS 博客文章）
+ [Scaling DynamoDB: How partitions, hot keys, and split for heat impact performance](https://aws.amazon.com/blogs/database/part-3-scaling-dynamodb-how-partitions-hot-keys-and-split-for-heat-impact-performance/)（AWS 博客文章）
+ [Multi-Region strong consistency with DynamoDB global tables](https://www.youtube.com/watch?v=R-nTs8ZD8mA)（AWS re:Invent 2024 演示）