全局表概述

关键事实

• 全局表有两个版本：版本 2017.11.29（旧版）（有时称为 v1）和版本 2019.11.21（当前）（有时称为 v2）。本指南只关注当前版本。

• DynamoDB（不带全局表）是一项区域服务，这意味着它具有高可用性，并且具有本质上的弹性，可以抵御基础设施故障，包括整个可用区的故障。单区域 DynamoDB 表专为 99.99% 的可用性而设计。有关更多信息，请参阅 DynamoDB 服务等级协议 (SLA)。

• DynamoDB 全局表在两个或多个区域之间复制其数据。多区域 DynamoDB 表专为 99.999% 的可用性而设计。通过适当的规划，全球表格可以帮助创建一个能够抵御区域故障的架构。

• DynamoDB 没有全局端点。所有请求都向区域终端节点发出，该终端节点访问该区域的本地全局表实例。

• 对 DynamoDB 的调用不应跨区域进行。最佳做法是让位于一个区域的应用程序仅直接访问其区域的本地 DynamoDB 终端节点。如果在某个区域（DynamoDB 层或周围堆栈）内检测到问题，则应将最终用户流量路由到托管在不同区域中的其他应用程序终端节点。全局表可确保驻留在每个区域的应用程序都能访问相同的数据。

一致性模式

创建全局表时，需要配置其一致性模式。全局表支持两种一致性模式：多区域最终一致性 (MREC) 和多区域强一致性 (MRSC)，后者于 2025 年 6 月推出。

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

有关 MREC 的关键事实

• 使用 MREC 的全局表采用主动-主动复制模型。从 DynamoDB 的角度来看，每个区域中的表在接受读取和写入请求方面具有同等地位。收到写入请求后，本地副本表会在后台将写入操作复制到其他参与的远程区域。

• 项目是单独复制的。在单个事务中更新的项目可能无法一起复制。

• 源区域中的每个表分区都与其他每个分区并行复制其写入操作。远程区域内的写入操作顺序可能与源区域内发生的写入操作顺序不匹配。有关表分区的更多信息，请参阅博客文章扩缩 DynamoDB：分区、热键和热拆分如何影响性能。

• 新写入的项目通常会在一秒内传播到所有副本表。附近区域的传播速度往往更快。

• Amazon 为每个区域组合 CloudWatch 提供了一个ReplicationLatency指标。它的计算方法是查看到达的物品，将它们的到达时间与初始写入时间进行比较，然后计算平均值。时间存储 CloudWatch 在源区域内。查看平均时间和最大时间对于确定平均和最坏情况下的复制滞后非常有用。对于这种延迟，没有 SLA。

• 如果在两个不同的区域中大约同时（在此ReplicationLatency窗口内）更新单个项目，而第二个写入操作发生在复制第一个写入操作之前，则可能会出现写入冲突。使用 MREC 的全局表根据写入操作的时间戳使用最后写入者获胜机制来解决此类冲突。第一个操作 “输给” 第二个操作。这些冲突未记录在 CloudWatch 或中 AWS CloudTrail。

• 每个项目都有最后一次写入时间戳，保留为一个私有系统属性。最后写入者获胜的方法是通过使用条件写入操作来实现的，该操作要求传入项目的时间戳大于现有项目的时间戳。

• 全球表格将所有项目复制到所有参与区域。如果您想要不同的复制范围，则可以创建多个全局表，并为每个表分配不同的参与区域。

• 即使副本区域处于离线状态或正在ReplicationLatency增长，本地区域也接受写入操作。本地表继续尝试将项目复制到远程表，直到每个项目成功为止。

• 万一某个区域完全脱机，当该区域稍后恢复联机时，将重试所有待处理的出站和入站复制。无需特殊操作即可使表恢复同步。最后一个写入者获胜机制可确保数据最终变得一致。

• 您可以随时向 DynamoDB MREC 表中添加新的区域。DynamoDB 负责处理初始同步和正在进行的复制。您也可以删除区域（甚至是原始区域），这将删除该区域中的本地表。

有关 MRSC 的关键事实

• 使用 MRSC 的全局表也采用主动-主动复制模型。从 DynamoDB 的角度来看，每个区域中的表在接受读取和写入请求方面具有同等地位。在写入操作返回成功响应之前，MRSC 全局表副本中的项目更改会同步复制到至少一个其他区域。

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

• MRSC 副本的最终一致性读取操作可能不包括最近在另一个区域发生的更改，甚至可能不包括最近在同一区域发生的更改。

• 当尝试修改已在其他区域修改的项目时，写入操作会失败，但会出现ReplicatedWriteConflictException异常。如果写入操作因ReplicatedWriteConflictException异常而失败，则可以重试，如果该项目不再在其他区域中被修改，则写入操作将成功。

• 使用 MRSC，写入操作和强一致性读取操作的延迟会更高。这些操作需要跨区域通信。这种通信往往会增加延迟，延迟会根据正在访问的区域与最近加入全局表的区域之间的往返延迟而增加。（有关更多信息，请参阅 re AWS : Invent 2024 演示文稿，多区域与 Amazon DynamoD B 全球表高度一致。） 最终，一致性读取操作不会出现额外的延迟。有一个开源测试工具，可让您通过实验计算区域的这些延迟。

• 项目是单独复制的。使用 MRSC 的全局表不支持该事务 APIs。

• MRSC 全球表必须恰好部署在三个区域。您可以将 MRSC 全局表配置为包含三个副本或两个副本和一个见证人。见证人是 MRSC 全局表的组成部分，该表包含最近写入全局表副本的数据。见证人提供了完整副本的可选替代方案，同时支持 MRSC 的可用性架构。您无法对见证者执行读取或写入操作。见证人不会产生存储或写入成本。目击者与两个副本位于不同的区域内。

• 要创建 MRSC 全局表，您可以添加一个副本和一个见证，或者向不包含任何数据的现有 DynamoDB 表中添加两个副本。您无法向现有 MRSC 全局表添加其它副本。您无法从 MRSC 全局表中删除单个副本或见证。您可以从 MRSC 全局表中删除两个副本，或者删除一个副本和一个见证。第二种场景将剩余的副本转换为单区域 DynamoDB 表。

• 您可以从 DescribeTableAPI 的输出中确定 MRSC 全局表是否配置了见证以及该表配置在哪个区域。见证人由 DynamoDB 拥有和管理，不会出现在 AWS 账户 配置见证人的区域中。

• MRSC 全局表在以下区域集中可用：

  • 美国区域集：美国东部（弗吉尼亚州北部）、美国东部（俄亥俄州）、美国西部（俄勒冈州）

  • 欧洲区域集：欧洲地区（爱尔兰）、欧洲地区（伦敦）、欧洲地区（巴黎）、欧洲地区（法兰克福）

  • AP 区域集：亚太地区（东京）、亚太地区（首尔）和亚太地区（大阪）

• MRSC 全局表不能跨区域集。例如，MRSC 全局表不能同时包含来自美国和欧盟区域集的副本。

• MRSC 全局表不支持生存时间 (TTL)。

• MRSC 全局表不支持本地二级索引 (LSIs)。

• CloudWatch 仅报告发生操作的区域的 “贡献者见解” 信息。

• 只要承载副本或见证的第二个区域可用于建立法定人数，本地区域就会接受所有读取和写入操作。如果第二个区域不可用，则本地区域只能为最终一致性读取提供服务。

• 万一某个区域完全离线，当它稍后重新上线时，它会自动赶上 catch。在它被赶上之前，写入操作和强一致性读取操作将返回错误。但是，最终一致性读取操作将返回迄今为止已传播到该区域的数据，在领导节点和本地副本之间具有通常的局部一致性行为。无需特殊操作即可使表格恢复同步

使用案例

MREC 全球表格提供了以下好处：

• 低延迟读取操作。您可以将数据副本放在离最终用户更近的地方，以减少读取操作期间的网络延迟。数据与ReplicationLatency值一样新鲜。

• 低延迟写入操作。最终用户可以写入附近的区域，以减少网络延迟和完成写入操作的时间。必须谨慎路由写入流量，以确保不存在冲突。路由技术将在后面的章节中讨论。

• 无缝的区域迁移。您可以添加一个新区域，然后删除旧区域，将部署从一个区域迁移到另一个区域，而无需在数据层停机。

MREC和MRSC全球表格都提供了以下好处：

• 改善了弹性和灾难恢复。如果某个区域的性能下降或完全中断，则可以将其撤出（也就是说，移除发往该区域的部分或全部请求）。使用全局表可将每月正常运行时间百分比的 DynamoDB 服务等级协议从 99.99% 提高到 99.999%。使用 MREC 支持以秒为单位的恢复点目标 (RPO) 和恢复时间目标 (RTO)。使用 MRSC 支持 RPO 为零。

  例如，富达投资在re: Invent 2022上介绍了他们如何使用DynamoDB全球表格作为订单管理系统。他们的目标是以本地处理无法实现的规模实现可靠的低延迟处理，同时保持对可用区和区域故障的弹性。

如果您的目标是弹性和灾难恢复，则 MRSC 表具有更高的写入延迟和更高的强一致性读取延迟，但支持 RPO 为零。MREC 全局表支持的 RPO 等于副本之间的复制延迟，通常为几秒钟，具体取决于副本区域。有关更多信息，请参阅 DynamoDB 文档中的一致性模式。