

# 全局表核心概念
<a name="globaltables-CoreConcepts"></a>

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

## 概念
<a name="globaltables-CoreConcepts.KeyConcepts"></a>

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

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

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

## 版本
<a name="globaltables-CoreConcepts.Versions"></a>

DynamoDB 全局表有两个版本：[全局表版本 2019.11.21（当前版）](GlobalTables.md)和[全局表版本 2017.11.29（旧版）](globaltables.V1.md)。您应尽可能使用全局表版本 2019.11.21（当前版本）。文档这一部分的信息适用于版本 2019.11.21（当前版）。有关更多信息，请参阅[确定全局表的版本](V2globaltables_versions.md#globaltables.DetermineVersion)。

## 可用性
<a name="globaltables-CoreConcepts.availability"></a>

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

全局表中的每个副本表都提供与单区域 DynamoDB 表相同的持久性和可用性。全局表提供 99.999% 的可用性[服务水平协议（SLA）](https://www.amazonaws.cn//dynamodb/sla/)，相比之下，单区域表提供 99.99% 的可用性。

## 故障注入测试
<a name="fault-injection-testing"></a>

MREC 和 MRSC 全局表都与 [Amazon 故障注入服务](https://docs.amazonaws.cn/resilience-hub/latest/userguide/testing.html)（Amazon FIS）集成，这是一项完全托管式服务，用于运行受控的故障注入实验，以提高应用程序的弹性。使用 Amazon FIS，您可以：
+ 创建用于定义特定故障场景的实验模板。
+ 通过模拟区域隔离（即暂停与选定副本之间的复制）来测试错误处理、恢复机制和一个 Amazon 区域出现中断时的多区域流量转移行为，从而注入故障以验证应用程序的弹性。

例如，在一个在美国东部（弗吉尼亚州北部）、美国东部（俄亥俄州）和美国西部（俄勒冈州）有副本的全局表中，您可以在美国东部（俄亥俄州）运行一个实验以测试此处的区域隔离，而美国东部（弗吉尼亚州北部）和美国西部（俄勒冈州）继续正常运行。这种受控测试有助于确定并解决潜在的问题，以防这些问题影响到生产工作负载。

有关 Amazon FIS 支持的操作的完整列表，请参阅《Amazon FIS 用户指南》**中的[操作目标](https://docs.amazonaws.cn/fis/latest/userguide/action-sequence.html#action-targets)；有关如何暂停 DynamoDB 在区域之间复制，请参阅[跨区域连接](https://docs.amazonaws.cn/fis/latest/userguide/cross-region-scenario.html)。

有关 Amazon FIS 中可用的 Amazon DynamoDB 全局表操作的信息，请参阅《Amazon FIS 用户指南》**中的 [DynamoDB 全局表操作参考](https://docs.amazonaws.cn/fis/latest/userguide/fis-actions-reference.html#dynamodb-actions-reference)。

要开始运行故障注入实验，请参阅《Amazon FIS 用户指南》中的[计划您的 Amazon FIS 实验](https://docs.amazonaws.cn/fis/latest/userguide/getting-started-planning.html)。

**注意**  
在 MRSC 中进行 Amazon FIS 实验期间，允许最终一致性读取，但不支持更新表设置（例如更改计费模式或配置表吞吐量），这与 MREC 类似。请检查 CloudWatch 指标 [`FaultInjectionServiceInducedErrors`](metrics-dimensions.md#FaultInjectionServiceInducedErrors)，以了解有关错误代码的更多详细信息。

## 生存时间（TTL）
<a name="global-tables-ttl"></a>

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

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

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

## 流
<a name="global-tables-streams"></a>

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

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

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

## 事务
<a name="global-tables-transactions"></a>

在配置为 MREC 的全局表上，DynamoDB 事务操作（[https://docs.amazonaws.cn/amazondynamodb/latest/APIReference/API_TransactWriteItems.html](https://docs.amazonaws.cn/amazondynamodb/latest/APIReference/API_TransactWriteItems.html) 和 [https://docs.amazonaws.cn/amazondynamodb/latest/APIReference/API_TransactGetItems.html](https://docs.amazonaws.cn/amazondynamodb/latest/APIReference/API_TransactGetItems.html)）仅在调用该操作的区域内才是原子操作。事务性写入不会作为一个单元跨区域复制，这意味着在给定时间点，其它副本中的读取操作可能只会返回事务中的部分写入内容。

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

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

## 读写吞吐量
<a name="globaltables-CoreConcepts.Throughput"></a>

### 预置模式
<a name="gt_throughput.provisioned"></a>

复制会消耗写入容量。如果应用程序写入吞吐量和复制写入吞吐量的组合超过了预置的写入容量，则配置为预置容量的副本可能会限制请求。对于使用预置模式的全局表，读取和写入容量的自动扩缩设置将在副本之间同步。

可以通过在副本级别使用 [https://docs.amazonaws.cn/amazondynamodb/latest/APIReference/API_ProvisionedThroughputOverride.html](https://docs.amazonaws.cn/amazondynamodb/latest/APIReference/API_ProvisionedThroughputOverride.html) 参数，为全局表中的每个副本独立配置读取容量设置。默认情况下，对预置读取容量的更改将应用于全局表中的所有副本。向全局表添加新副本时，除非明确指定了副本级别覆盖，否则将使用源表或副本的读取容量作为初始值。

### 按需模式
<a name="gt_throughput.on-demand"></a>

对于配置为按需模式的全局表，写入容量会在所有副本之间自动同步。DynamoDB 会根据流量自动调整容量，并且无需管理特定于副本的读取或写入容量设置。

## 监控全局表
<a name="monitoring-global-tables"></a>

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

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

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

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

## 管理全局表的注意事项
<a name="management-considerations"></a>

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

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