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

DynamoDB 全局表工作原理

以下各节介绍 Amazon DynamoDB 中全局表的概念和行为。

概念

全局表是一项 DynamoDB 功能，可跨 Amazon 区域复制表数据。

副本表（或副本）是一个 DynamoDB 表，它作为全局表的一部分发挥作用。一个全局表由跨不同 Amazon 区域的两个或更多副本表组成。对于每个 Amazon 区域，每个全局表只能有一个副本。全局表中的所有副本共享相同的表名称、主键架构和项目数据。

当应用程序将数据写入一个区域中的副本时，DynamoDB 会自动将写入内容复制到全局表中的所有其它副本。有关如何开始使用全局表的更多信息，请参阅 教程：创建全局表。

版本

DynamoDB 全局表有两个版本可用：版本 2019.11.21（当前版）和版本 2017.11.29（旧版）。您应尽可能使用版本 2019.11.21（当前版）。文档这一部分的信息适用于版本 2019.11.21（当前版）。有关更多信息，请参阅 确定全局表的版本。

可用性

全局表可以更轻松地实施多区域高可用性架构，从而有助于提高业务连续性。如果单个 Amazon 区域中的工作负载受损，则可以将应用程序流量转移到不同的区域，并对同一个全局表中的其它副本表执行读取和写入操作。

全局表中的每个副本表都提供与单区域 DynamoDB 表相同的持久性和可用性。全局表提供 99.999% 的可用性服务水平协议（SLA），相比之下，单区域表提供 99.99% 的可用性。

一致性模式

创建全局表时，可以配置其一致性模式。全局表支持两种一致性模式：多区域最终一致性（MREC）和多区域强一致性（MRSC）。

如果您在创建全局表时未指定一致性模式，则全局表默认为多区域最终一致性（MREC）。全局表不能包含配置了不同一致性模式的副本。创建全局表后，无法更改其一致性模式。

多区域最终一致性（MREC）

多区域最终一致性（MREC）是全局表的默认一致性模式。MREC 全局表副本中的项目更改通常会在一秒或更短的时间内异步复制到所有其它副本。万一 MREC 全局表中的副本变得孤立或受损，任何尚未复制到其它区域的数据将在该副本恢复正常时进行复制。

如果在多个区域中同时修改同一个项目，DynamoDB 将基于每个项目使用具有最新内部时间戳的修改来解决冲突，称为“最后写入者为准”冲突解决方法。一个项目最终将在所有副本中会聚至由最后一次写入创建的版本。

如果项目是在发生读取的区域中进行最后一次更新的，则 Strongly consistent read operations 会返回该项目的最新版本；但如果该项目是在其它区域中进行最后一次更新的，则可能会返回陈旧的数据。条件写入会根据区域中项目的版本来评估条件表达式。

您可以通过向现有 DynamoDB 表添加副本来创建 MREC 全局表。添加副本不会影响现有单区域 DynamoDB 表或全局表副本的性能。您可以向 MREC 全局表中添加副本以扩大复制数据的区域数量，或者如果不再需要副本，则可以从 MREC 全局表中移除副本。MREC 全局表可以在 DynamoDB 可用的任何区域中有一个副本，并且可以拥有与 Amazon partition 中的区域数量一样多的副本。

多区域强一致性（MRSC）

创建全局表时，可以配置多区域强一致性（MRSC）模式。在写入操作返回成功响应之前，MRSC 全局表副本中的项目更改会同步复制到至少一个其它区域。

对任何 MRSC 副本执行的强一致性读取操作始终返回项目的最新版本。条件写入始终根据项目的最新版本来评估条件表达式。

当写入操作尝试修改已在另一个区域中处于正在修改状态的项目时，此操作将失败并引发 ReplicatedWriteConflictException。可以重试失败并引发了 ReplicatedWriteConflictException 的写入操作，如果该项目不再在另一个区域中处于正在修改状态，则写入将成功。

您可以将 MRSC 全局表配置为具有三个副本或具有两个副本和一个见证者。见证者是 MRSC 全局表的一个组成部分，它包含写入全局表副本的数据，并在支持 MRSC 的可用性架构的同时，为完整副本提供了一种可选的替代方案。您无法对见证者执行读取或写入操作。见证者位于与两个副本不同的区域中。

创建 MRSC 全局表时，您可以在创建 MRSC 表时为副本和见证者部署选择区域。您可以从 DescribeTable API 的输出中，确定 MRSC 全局表是否配置了见证者以及在哪个区域中配置了见证者。见证者由 DynamoDB 拥有和管理，并且在配置了见证者的区域中，见证者不会出现在您的 Amazon 账户中。

MRSC 全局表必须部署在恰好三个区域中。您可以通过向不包含任何数据的现有 DynamoDB 表中添加一个副本和一个见证者或两个副本来创建 MRSC 全局表。您无法向现有 MRSC 全局表添加其它副本。您无法从 MRSC 全局表中删除单个副本表或见证者。您可以从 MRSC 全局表中删除两个副本，或者删除一个副本和一个见证者，同时将剩余的副本转换为单区域 DynamoDB 表。

以下注意事项适用于 MRSC 全局表：

选择一致性模式

选择多区域一致性模式的关键标准是：应用程序是优先考虑低延迟写入和强一致性读取，还是优先考虑全局强一致性。

与 MRSC 全局表相比，MREC 全局表将具有更低的写入延迟和强一致性读取延迟。MREC 全局表可以支持与副本间的复制延迟相等的恢复点目标（RPO），通常为几秒，具体取决于副本所在的区域。

在以下情况下，应使用 MREC 模式：

与 MREC 全局表相比，MRSC 全局表将具有更高的写入延迟和强一致性读取延迟。MRSC 全局表支持恢复点目标（RPO）为零。

在以下情况下，应使用 MRSC 模式：

监控全局表

配置为多区域最终一致性（MREC）的全局表会将 ReplicationLatency 指标发布到 CloudWatch。此指标跟踪从一个项目写入到副本表到该项目出现在全局表的另一个副本中之间经过的时间。ReplicationLatency 以毫秒表示，并针对全局表中的每个源区域和目标区域对发出。

典型的 ReplicationLatency 值取决于所选 Amazon 区域之间的距离以及工作负载类型和吞吐量等其它变量。例如，与非洲（开普敦）（af-south-1）区域相比，美国西部（北加利福尼亚）（us-west-1）区域的源副本到美国西部（俄勒冈州）（us-west-2）区域的 ReplicationLatency 更低。

ReplicationLatency 值不断增加可能表明来自一个副本的更新没有及时传播到其它副本表。在这种情况下，可以临时将应用程序的读取和写入活动重定向到不同的 Amazon 区域。

配置为多区域强一致性（MRSC）的全局表不发布 ReplicationLatency 指标。

故障注入测试

MREC 全局表与 Amazon Fault Injection Service（Amazon FIS）集成，来对全局表工作负载执行故障注入实验。这样，您就能够通过暂停与选定副本之间的复制，来测试应用程序对模拟区域隔离的响应。有关更多信息，请参阅 pausing global table replication。

生存时间（TTL）

配置为 MREC 的全局表支持配置生存时间（TTL）删除。全局表中所有副本的 TTL 设置会自动同步。当 TTL 从某个区域的副本中删除项目时，该删除操作会复制到全局表中的所有其它副本。TTL 不占用写入容量，因此您无需为发生删除的区域中的 TTL 删除付费。但是，对于全局表中具有副本的每个其它区域，您需要对复制的删除操作付费。

对于要向其复制删除操作的副本，TTL 删除复制会占用写入容量。如果写入吞吐量和 TTL 删除吞吐量的组合高于预置的写入容量，则配置为预置容量的副本可能会限制请求。

配置为多区域强一致性（MRSC）的全局表不支持配置生存时间（TTL）删除。

流

配置为多区域最终一致性（MREC）的全局表可通过从副本表上的 DynamoDB 流读取这些更改，并将该更改应用于所有其它副本表，从而复制更改。因此，默认情况下，对 MREC 全局表中的所有副本都启用了流，并且无法在这些副本上禁用流。MREC 复制过程可能会在短时间内将多项更改合并到单个复制写入操作中，从而导致每个副本的流包含的记录略有不同。MREC 副本上的流记录始终按每个项目排序，但项目间的排序可能在副本之间有所不同。

配置为多区域强一致性（MRSC）的全局表不使用 DynamoDB Streams 进行复制，因此默认情况下不在 MRSC 副本上启用流。您可以在 MRSC 副本上启用流。MRSC 副本上的流记录对于每个副本都是相同的，包括流记录排序。

如果您要编写一个应用程序，用于处理全局表中在特定区域（而非其它区域）发生的更改的流记录，则可以为每个项目添加一个属性，以定义该项目的更改发生在哪个区域。您可以使用此属性来筛选流记录，以了解在其它区域中发生的更改，包括使用 Lambda 事件筛选条件仅针对特定区域中的更改调用 Lambda 函数。

事务

在配置为 MREC 的全局表上，DynamoDB 事务操作（TransactWriteItems 和 TransactGetItems）仅在调用该操作的区域内才是原子操作。事务性写入不会作为一个单元跨区域复制，这意味着在给定时间点，其它副本中的读取操作可能只会返回事务中的部分写入内容。

例如，如果您有一个全局表，该表在美国东部（俄亥俄州）和美国西部（俄勒冈州）区域中具有副本，并且在美国东部（俄亥俄州）区域中执行 TransactWriteItems 操作，则在复制更改时，可能会在美国西部（俄勒冈州）区域观察到部分完成的事务。更改仅在源区域中提交后才会复制到其它区域。

配置为多区域强一致性（MRSC）的全局表不支持事务操作，如果对 MRSC 副本调用这些操作，则会返回错误。

读写吞吐量

复制会消耗写入容量。如果写入吞吐量和复制吞吐量的组合高于预置的写入容量，则配置为预置容量的副本可能会限制请求。按需模式下的写入容量将针对全局表中的所有副本进行同步。配置为预置容量的全局表会在副本之间同步自动扩缩设置。根据消耗的写入吞吐量，副本之间的实际预置写入容量设置可能会有所不同。

您可以为全局表中的每个副本独立配置读取容量设置。向全局表添加副本时，除非指定了覆盖值，否则将使用源表或副本的读取容量作为初始值。

设置同步

DynamoDB 全局表中的设置是控制表行为和复制的各个方面的配置参数。这些设置可通过 DynamoDB 控制面板 API 进行管理，并可以在创建或修改全局表时进行配置。全局表会自动在所有副本间同步某些设置以保持一致性，同时可以灵活地进行特定于区域的优化。了解哪些设置会同步以及它们的行为方式，有助于您有效地配置全局表。根据这些设置在副本间的同步方式，可分为三个主要类别。

以下设置始终在全局表中的副本之间同步：

以下设置在副本之间同步，但可以根据每个副本进行覆盖：

以下设置从不会在副本之间同步：

所有其它设置均不会在副本之间同步。

DynamoDB Accelerator (DAX)

对全局表副本的写入会绕过 DynamoDB Accelerator（DAX），而直接更新 DynamoDB。因此，由于写入操作未更新 DAX 缓存，DAX 缓存可能变得过时。为全局表副本配置的 DAX 缓存只有在缓存 TTL 到期时才会刷新。

管理全局表的注意事项

在创建新的全局表副本后的 24 小时内，您无法删除用于添加该新副本的表。

如果您禁用包含全局表副本的 Amazon 区域，则在禁用该区域的 20 小时后，这些副本将永久转换为单区域表。