使用 DynamoDB Global Tables 构建多区域数据库 - 主动-主动复制
通过多区域主动-主动复制实现低延迟读写。介绍冲突解决机制和灾难恢复设计。
Global Tables 概述
Global Tables 是将 DynamoDB 表复制到多个区域的多区域数据库。与 Aurora Global Database 的读写分离架构不同，Global Tables 提供所有区域均可读写的主动-主动配置。2022 年发布的版本 2019.11.21 (V2) 中，副本表具有与普通 DynamoDB 表相同的功能，包括本地二级索引和按需容量模式。副本的添加和删除也可在不停止表写入的情况下执行。
复制与灾难恢复
添加副本表只需在控制台选择区域，现有数据会自动复制。写入在各区域的本地表执行，异步复制到其他区域。当同一项目在多个区域同时更新时，通过最后写入者获胜（时间戳最新的写入优先）自动解决。在灾难恢复设计中，通过 Route 53 的健康检查和故障转移，在主区域故障时自动切换到备用区域。故障转移 RTO 取决于复制延迟（通常 1 秒以内）和 DNS TTL，因此将 TTL 设置为 60 秒以下可缩短切换时间。
冲突解决与最佳实践
Global Tables 采用最后写入者获胜（Last Writer Wins）的冲突解决策略，时间戳最新的写入优先。当同一项目发生并发写入时，应在应用层实现乐观锁（基于版本号的条件写入）来检测冲突。副本间的复制延迟通常在 1 秒以内，但取决于区域间的距离。Global Tables 的流在各副本独立处理，因此确保 Lambda 触发器的幂等性设计非常重要。 要深入理解多区域设计和运维，专业书籍 (Amazon)会有所帮助。
与 Aurora Global Database 的比较
Global Tables 和 Aurora Global Database 都提供多区域配置，但架构和适用场景不同。Global Tables 是主动-主动模式，所有区域可写入；Aurora Global Database 采用读副本架构，仅主区域可写入。Global Tables 的复制是异步且最终一致的，而 Aurora 可通过写转发功能从次要区域经主区域写入（会增加延迟）。从数据模型角度，DynamoDB 提供键值和文档模型，Aurora 提供关系型 SQL。需要低延迟键值访问且全球主动-主动写入时选择 Global Tables，需要复杂 SQL 查询和 ACID 事务时选择 Aurora Global Database。故障转移时间也有差异：Global Tables 取决于复制延迟加 DNS TTL，Aurora 的提升操作需要数十秒。
费用与限制注意事项
Global Tables 的复制写入按与普通写入相同的 WCU/WRU 计费。双区域配置下写入成本约为 2 倍。复制的数据传输费用免费。读取从各区域的本地副本执行，不产生额外的读取成本。对于写入少读取多的工作负载，Global Tables 的成本增加有限。可以为每个区域独立设置容量，根据流量模式进行优化。表大小和项目数没有上限，但单个项目必须在 400 KB 以下。分区键设计不均匀会导致复制吞吐量瓶颈，因此避免热分区的设计至关重要。全局二级索引 (GSI) 也会在区域间复制，因此 GSI 写入成本也会在每个区域产生。
总结
Global Tables 是提供主动-主动多区域 DynamoDB 的服务。通过 1 秒以内的复制延迟实现区域间数据同步，使用最后写入者获胜的冲突解决维护一致性。读取从本地副本执行，额外成本有限，同时实现灾难恢复和全球低延迟访问。需要关系模型和 ACID 事务时选择 Aurora Global Database，键值的主动-主动配置则选择 Global Tables。