使用 DynamoDB 全局表 - Amazon DynamoDB
关键事实关于 MREC 的关键事实关于 MRSC 的关键事实使用案例结论和资源
Amazon Web Services 文档中描述的 Amazon Web Services 服务或功能可能因区域而异。要查看适用于中国区域的差异，请参阅 中国的 Amazon Web Services 服务入门 (PDF)。

使用 DynamoDB 全局表

全局表基于遍布全球的 Amazon DynamoDB 而构建，可提供完全托管式、多区域和多活动数据库，为大规模的全球应用程序提供高速的本地读写性能。全局表可在您选择的 Amazon Web Services 区域 自动复制 DynamoDB 表。全局表使用现有的 DynamoDB API，因此无需更改应用程序。使用全局表无需支付任何预付费用，也没有任何承诺，您只需为实际使用的资源付费。

本指南将介绍如何有效使用 DynamoDB 全局表。它提供有关全局表的关键事实，解释该功能的主要使用案例，描述两个一致性模式，介绍您应考虑的三种不同写入模型的分类法，引导您了解可以实施的四种主要请求路由选择，讨论撤离处于活动状态的区域或离线区域的方法，解释如何考虑吞吐能力规划，并提供了部署全局表时需要考虑的事项核对清单。

本指南适用于更广泛的 Amazon 多区域部署背景，如 Amazon 多区域基础知识白皮书和 Data resiliency design patterns with Amazon 视频中所述。

主题

关于 DynamoDB 全局表设计的关键事实

  • 全局表有两个版本：当前版本全局表版本 2019.11.21（当前版）（有时称为“V2”）和 全局表版本 2017.11.29（旧版）（有时称为“V1”）。本指南仅关注当前版本。

  • DynamoDB（不含全局表）是一项区域服务，这意味着它具有高可用性，且对基础设施故障具有内在的弹性，包括整个可用区的故障。单区域 DynamoDB 表设计为具有 99.99% 的可用性。有关更多信息，请参阅 DynamoDB 服务水平协议（SLA）。

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

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

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

一致性模式

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

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

关于 MREC 的关键事实

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

  • 项目是单独复制的。在单个事务内更新的项目不能一起复制。

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

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

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

  • 如果大约在同一时间（在此 ReplicationLatency 时段内）在两个不同的区域更新单个项目，并且第二次写入操作发生在复制第一次写入操作之前，则可能会出现写入冲突。使用 MREC 的全局表会基于写入操作时间戳，采用以最后写入者为准的机制来解决此类冲突。第一个操作“输给了”第二个操作。这些冲突不会记录在 CloudWatch 或 Amazon CloudTrail 中。

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

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

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

  • 在极少数情况下，如果某个区域完全离线，则当该区域稍后恢复在线时，将重试所有待处理的出站和入站复制。无需特殊操作即可使表恢复同步。以最后写入者为准机制可确保数据最终实现一致性。

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

关于 MRSC 的关键事实

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

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

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

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

  • 使用 MRSC，写入操作和强一致性读取操作的延迟会更高。这些操作需要跨区域通信。此通信会增加延迟，延迟会根据正在访问的区域与加入全局表的最近区域之间的往返延迟而增加。有关更多信息，请参阅 Amazon re:Invent 2024 演示：Multi-Region strong consistency with DynamoDB global tables。最终一致性读取操作不会出现额外的延迟。您可以使用开源测试工具，通过实验计算区域的这些延迟。

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

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

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

  • 您可以从 DescribeTable API 的输出中，确定 MRSC 全局表是否配置了见证者以及在哪个区域中配置了见证者。见证者由 DynamoDB 拥有和管理，并且在配置了见证者的区域中，见证者不会出现在您的 Amazon Web Services 账户中。

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

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

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

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

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

  • MRSC 全局表不支持生存时间（TTL）。

  • MRSC 全局表不支持本地二级索引（LSI）。

  • CloudWatch Contributor Insights 信息仅针对发生操作的区域进行报告。

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

  • 在极少数情况下，如果某个区域完全离线，那么当它稍后重新上线时，会自动赶上进度。在它赶上进度之前，只有对正在赶进度的区域执行的写入操作和强一致性读取操作会返回错误，而对其他区域的请求将继续正常执行。对正在赶进度的区域执行的最终一致性读取操作将返回到目前为止已传播到区域中的数据，并且领导节点和本地副本之间具有通常的本地一致性行为。无需特殊操作即可使表恢复同步。

MREC DynamoDB 全局表使用案例

MREC 全局表提供以下好处：

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

  • 低延迟写入操作。您可以写入附近的区域以减少网络延迟和完成写入所需的时间。必须谨慎路由写入流量，以确保没有冲突。DynamoDB 中的路由策略中详述了路由技术。

  • 无缝的区域迁移。您可以添加新区域并删除旧区域，以便将部署从一个区域迁移到另一个区域，而且数据层不会出现任何停机时间。

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

  • 改善了弹性和灾难恢复。如果某个区域性能下降或完全中断，您可以将其撤离。撤离意味着将发送到该区域的部分或全部请求转走。使用全局表可将 DynamoDB SLA 的月度正常运行时间百分比从 99.99% 提高到 99.999%。使用 MREC 支持以秒为单位的恢复点目标（RPO）和恢复时间目标（RTO）。使用 MRSC 支持零 RPO。

    例如，Fidelity Investments 在 re:Invent 2022 大会上介绍了他们如何为其订单管理系统使用 DynamoDB 全局表。他们的目标是在大规模处理中，实现本地处理所无法实现的可靠低延迟，同时还在可用区和区域出现故障时保持韧性。

如果您的目标是韧性和灾难恢复，则 MRSC 表具有更高的写入延迟和更高的强一致性读取延迟，而且支持零 RPO。MREC 全局表支持与副本间的复制延迟相等的 RPO，通常为几秒，具体取决于副本所在的区域。

结论和资源

DynamoDB 全局表的控件很少，但仍然需要仔细考虑。您必须确定您的写入模式、路由模型和撤离过程。您必须针对每个区域对应用程序进行检测，并准备好调整路由或执行撤离，以维护全局运行状况。回报是拥有一个全球分布的数据集，该数据集可以实现低延迟的读取和写入操作，可用性设计为 99.999%。

有关 DynamoDB 全局表的更多信息，请参阅以下资源：