DynamoDB Global Tables
一张 global table 是一张跨多个 AWS 区域复制的 DynamoDB 表，其中每个副本都是可写的。 DynamoDB 自动让它们保持同步 —— 你在每个区域都获得低延迟的本地读写，外加跨区域灾难恢复，而 无需自己运行复制。
在审计日志的场景中，一个 EU 客户要求他们的数据驻留在 eu-west-1，而其余部分则跑在
us-east-1。而且作为一份对合规至关重要的日志，它需要在一次整区域宕机中存活下来。一张 global
table 用一个特性就回答了这两点。
什么是 DynamoDB Global Tables？
DynamoDB Global Tables 是一张跨多个 AWS 区域复制的单一表，其中每个副本都可读可写。DynamoDB 通过最终一致的异步复制自动让它们保持同步，并按最后写入者胜出来解决冲突。你在每个区域都获得低延迟的本地读写，外加跨区域灾难恢复，从而支撑 DynamoDB 99.999% 的可用性 SLA。
- 多区域、多活。 每个副本都完全可读可写；任一区域的写入都会传播到其他区域。
- 复制是异步的，且跨区域最终一致 —— 通常在一秒之内，但并非瞬时。
- 冲突按最后写入者胜出解决。 在两个区域对同一项的并发写入会调和到最近的那一个。
- 它支撑 99.999% 的可用性 SLA —— 一张多区域 global table 是 DynamoDB 可用性最高的配置。
问题所在：一个区域不够用
一张单区域的表有两个审计日志无法接受的局限。第一，数据驻留：一个 EU 客户的事件必须存储
在 EU，但你的应用跑在美国。第二，灾难恢复：如果 us-east-1 宕机，一份单区域的审计日志在
宕机期间既读不了也写不了 —— 而那恰恰是你最需要那份记录的时候。
自己构建其中任何一项 —— 跨区域复制、故障切换、冲突处理 —— 都是一个庞大且易错的工程。Global tables 把它变成了一个配置选项。
Global tables 如何工作
你向表添加一个副本区域；DynamoDB 在那里创建一份副本并让所有副本保持同步。据 AWS DynamoDB 常见问题所述，global tables 提供多区域复制， 可用性高达 99.999%，且每个区域的副本都服务本地读写。
两条一致性规则定义了其行为：
- 跨区域复制是异步的。 一次在
us-east-1的写入会在本地被确认，然后再传播到eu-west-1—— 通常在一秒之内，但紧随一次写入之后在另一个区域的读取可能尚未看到它。（强一致读取仍然有效， 但只在单个区域之内。） - 冲突按最后写入者胜出。 如果同一个项在两个区域几乎同时被写入，DynamoDB 会保留时间戳最新 的那个写入，并丢弃另一个。
一个实战示例：既是 EU 副本又是 DR
你把 eu-west-1 添加为审计日志表的一个副本。现在：
| write region | item | visible in | |
|---|---|---|---|
| us-east-1 | TENANT#acme | EVENT#…#a1 | both regions (~1s lag to EU) |
| eu-west-1 | TENANT#bmw | EVENT#…#e7 | both regions (~1s lag to US) |
EU 客户的应用向本地的 eu-west-1 副本写入并从中读取 —— 低延迟，且数据在区域内驻留。满足驻留
需求的这同一份复制，同时兼任灾难恢复：如果 us-east-1 宕机，eu-west-1 副本仍持有完整的
日志并服务流量；你切换到它即可。
由于审计日志是仅追加且按租户分区的，最后写入者胜出在这里基本不成问题 —— 一个给定租户的 事件是从一个区域写入的，且事件键唯一，因此两个区域很少在同一个项上竞争。这不是运气；这正是 为什么仅追加日志是 global tables 最干净的契合之一。相比之下，一个可变的计数器就需要在并发的 跨区域写入下小心处理。
在 DynoTable 中操作
在添加一个副本之后，你希望确认数据确实落到了新区域并与源相符 —— 即 EU 副本真的持有 acme 的
事件、带着正确的属性，且没有滞后。
DynoTable 能用各自的凭证连接到任意区域，因此你可以把一个窗口指向 us-east-1、另一个指向
eu-west-1，并排比对同一个租户的项，以验证复制。
你可以在 DynamoDB 表达式构建器中原型化你将对每个副本运行 的按区域查询。
坑与后续步骤
- 不要跨区域读取你自己刚写的内容。 复制滞后意味着一个区域的写入可能要约一秒后才出现在 另一个区域。不要在美国写入然后立刻从 EU 读取并指望看到它；强一致只限于单个区域。
- 最后写入者胜出会悄悄丢弃数据。 对于在两个区域并发写入的可变项，落败者会被无错误地丢弃。 仅追加或每项单写入者的设计（就像这份审计日志）可以避开这个问题；共享的可变状态则需要一个 感知冲突的设计。
- 每个副本都有成本。 每个区域都存储一份完整副本，并计费其自己的容量和存储 —— 一个副本大致 使成本翻倍。为真实的驻留或 DR 需求添加区域，而不要默认就加。
- 备份是按副本进行的。 一张恢复出的 global table 会成为一张独立的表 —— 请按区域规划恢复。 参见备份与时间点恢复。
Global tables 防范丢失一个区域。最后一个运维方面的考量是防范丢失数据 —— 一次糟糕的部署或 意外的删除 —— 用备份与时间点恢复。
下载 DynoTable，连接到多个区域并验证你的 global-table 副本持有相同的数据。