题干与适用场景
订单、用户偏好或库存服务需要在多个 Region 提供本地读写。请比较 DynamoDB Global Tables 的 MREC（多区域最终一致）和 MRSC（多区域强一致），说明写入路由、冲突处理、故障切换、容量和恢复方案。题目考察的是数据一致性与运营边界，不是把数据库简单复制到另一地区。
Global Tables 是托管的多区域、多活复制能力，任意副本都可以读写。MREC 是默认模式，变更异步传播；同一 item 在不同 Region 近同时修改时，DynamoDB 以 item 粒度的内部时间戳执行 last-writer-wins。MRSC 在写成功前同步复制到至少一个其他 Region，强一致读取可在任一副本返回最新值，但必须恰好部署三个 Region（三个副本，或两个副本加一个 witness）。
面试官考察点
高质量回答会先把业务不变量拆成 item、分区键和跨 item 事务，再根据 RPO、写延迟和读一致性选择模式。面试官会追问“最后写入者”是否会静默覆盖业务状态、MRSC 的三 Region 约束、MREC 事务的跨区可见性，以及区域隔离后的回流顺序。
只回答“开启多区域复制”不够。还要说明请求应访问本地 Region endpoint、如何避免双写同一 item、如何监控 ReplicationLatency、如何处理删除标记、重试和重复事件。
回答前需要澄清的问题
业务不变量与冲突形状
确认订单状态是否允许回退、库存是否必须线性一致、同一 item 是否可能被多个 Region 同时修改。若字段可独立合并，可拆成不同 item 或带版本的子记录；若必须跨字段原子更新，要评估 MREC 的事务只在调用 Region 内原子、不会以事务单元跨区复制的限制。
RPO、延迟与区域数量
询问可接受的 RPO、P99 写延迟、故障切换时间和合规 Region。MREC 可在任意可用 Region 建副本并通常在一秒内传播；MRSC 牺牲部分写延迟换取跨区强读与零 RPO 目标，但固定需要三个 Region。
写入归属与恢复策略
明确是多活写入，还是每个租户有 home Region、其他 Region 只读。若业务无法接受 LWW，应使用 IAM 或路由策略限制写入 Region，并在恢复时定义谁拥有冲突裁决权，而不是让复制层替业务决定。
30 秒回答框架
“我先按业务不变量选择模式：库存扣减和跨区强读需要 MRSC，接受短暂陈旧且更看重本地写延迟则用默认 MREC。MREC 采用异步复制和 item 粒度 LWW，因此我会让同一订单或租户固定到 home Region，并用条件写、幂等键和显式版本防止重复更新；无法合并的状态不会依赖 LWW。所有请求访问本地 endpoint，跨区故障时切换应用流量而不是让客户端跨区调用。监控 ReplicationLatency、复制失败和条件写失败，恢复后按版本、事件日志和业务规则重放并审计。”
分步骤深入解答
第一步：选择一致性模式
MREC 默认、可部署在任意数量的 Region，副本之间最终一致，适合用户偏好、目录和可接受短暂陈旧的读模型。MRSC 写入会同步复制到至少一个其他 Region，任意副本的强一致读都能看到最新值；它要求恰好三个 Region，且不支持事务操作。模式在创建时确定，不能把同一张 Global Table 的副本混用，也不能事后切换模式。
第二步：定义写入拓扑
每个应用优先访问所在 Region 的 DynamoDB endpoint。多活写入只有在业务能处理并发冲突时才开放；订单、库存等强约束对象可采用 home-Region 写入、其他 Region 读，或把状态拆成按租户/订单归属的单写分区。跨 Region 直接调用会放大延迟和故障面，流量切换应由应用入口或路由层完成。
第三步：在 MREC 中约束冲突
MREC 对同一 item 的近同时更新使用内部时间戳的 LWW，所有副本最终收敛，但被淘汰的业务变更不会自动进入补偿流程。使用条件表达式检查版本，写入携带幂等请求 ID；对不可覆盖的状态保存追加事件或冲突记录。删除也要有明确的 tombstone 或状态字段，避免旧副本的更新重新“复活”已删除对象。
第四步：处理事务与重试
MREC 的 TransactWriteItems 只在发起 Region 内原子，复制到其他 Region 时可能暂时看到部分结果，因此不要把跨区读当成事务提交确认。客户端重试必须区分条件失败、限流和复制延迟，使用有上限的指数退避与幂等键。MRSC 不支持事务操作，跨 item 不变量需要重新建模或由服务层协调。
第五步：规划故障切换和恢复
监控复制延迟、复制错误、条件写失败、请求 Region 和业务版本。Region 隔离时，将入口流量切到健康 Region；若使用 MREC，先暂停受冲突影响的写路径或切换租户 home Region，记录切换时间和最后可见版本。恢复后按事件日志、版本和业务规则校验收敛结果，不能仅以“所有副本最终相同”判断库存或订单正确。
第六步：容量、安全与治理
每个副本都要评估读写容量、自动扩缩容和限额；新增副本会继承源 Region 的容量设置，创建后再独立调整。启用每个副本的删除保护，使用 IAM 限制写入 Region 和表操作，KMS 密钥权限失效会停止相应复制。多账号模型支持 MREC，不适用于 MRSC，治理方案要把账户、Region 和审计责任写清楚。
第七步：验证与演练
用两 Region 并发写同一 item、条件写重试、网络分区、删除与迟到更新、复制延迟尖峰、入口切换和恢复回流做演练。验证副本最终收敛、业务补偿事件完整、幂等重放不重复扣库存，并将 ReplicationLatency 与冲突计数关联到请求 ID。压测要覆盖真实 Region 距离和容量模式，不能用单机延迟推断跨区表现。
高质量示范回答
我会先按不变量选模式。需要跨 Region 强一致读取、零 RPO 目标的关键数据才考虑 MRSC，并接受它必须恰好三个 Region、写延迟更高且不支持事务的约束；一般目录或偏好数据使用 MREC。MREC 的异步复制和 item 粒度 LWW 不能替业务合并冲突，所以订单与库存采用租户或订单 home Region 单写、条件表达式、版本号和幂等键；可合并字段拆成独立 item，无法合并的变更写入冲突事件。
应用只访问本地 endpoint，入口层负责 Region 故障切换。监控 ReplicationLatency、复制失败、条件写失败和版本差异，限流与复制延迟使用有限退避。故障恢复时先冻结受影响写入，按事件日志和业务规则校验收敛结果，再逐步放开流量。容量、删除保护、IAM 和 KMS 权限按每个副本审计，并用并发写、分区、迟到删除和重复重放演练证明方案成立。
常见错误
- 错误表现： 看到 Global Tables 就默认使用多活写入。→ 失败原因： MREC 的 LWW 可能丢掉不可合并的业务变更。→ 修正方法： 固定写入归属，或显式设计版本、事件和补偿。
- 错误表现： 把 MREC 的跨区事务当成全局原子。→ 失败原因： 事务只在调用 Region 内原子，其他副本可能暂时看到部分结果。→ 修正方法： 重新建模跨区不变量，使用事件和幂等协调。
- 错误表现： 只在延迟超时后盲目切换 Region。→ 失败原因： 双写会扩大冲突和回流风险。→ 修正方法： 先暂停或限定写入，记录版本，再按租户或业务边界切换。
- 错误表现： 认为副本收敛就等于库存正确。→ 失败原因： LWW 只解决复制冲突，不理解业务语义。→ 修正方法： 用条件写、事件日志、补偿任务和审计验证业务结果。
追问及应对
追问一：什么时候选 MRSC？
当跨 Region 的强一致读和零 RPO 比写延迟、Region 选择自由度更重要时选择 MRSC。它要求恰好三个 Region（可含一个 witness），并且不支持事务；若业务依赖任意数量副本或跨账号模型，应重新评估 MREC 与服务层协调。
追问二：LWW 覆盖了库存扣减怎么办？
不要依赖 LWW 恢复数量。为扣减使用条件表达式和版本，按商品或库存分片固定写入归属；将每次扣减写入幂等事件，冲突检测任务比较事件序列并生成补偿或人工队列。读取库存时同时检查版本和可见时间。
追问三：MREC 复制延迟升高时怎么处理？
告警按源 Region、目标 Region 和业务影响分组，先限制跨 Region 写入或切换到 home Region，避免继续制造冲突。客户端重试要有上限，恢复后核对版本、迟到事件和删除标记，再逐步恢复多活。ReplicationLatency 只能说明传播时间，不能替代业务正确性检查。
追问四：如何测试区域故障后的回流？
演练入口切换、旧 Region 恢复、双端请求重放和迟到删除。记录每个请求的 Region、版本和幂等 ID，验证旧 Region 不会以陈旧版本覆盖新状态，冲突事件可追溯，补偿任务可重复执行。演练结果应包含 RPO、RTO、冲突数和人工介入量。
追问五：为什么不能混用 MREC 和 MRSC 副本？
一致性模式属于整张 Global Table 的创建配置，副本不能采用不同模式，也不能在创建后切换。若需求变化，应规划新表、数据迁移和双写/回放窗口，并先验证容量、权限、客户端兼容和回滚路径。