ReplicatedWriteConflictException

TL;DR — 你在一张多区域强一致性（MRSC）全局表上写入了一个项目，而_另一个区域_的一个请求正在修改同一个项目。多区域强一致性不能让两个写入都落地，因此一个写入被拒绝。AWS 记载它可重试：退避并重试，并尽可能减少热点项目上的跨区域争用。

含义

ReplicatedWriteConflictException: One or more items in this request are
being modified by a request in another Region.

经典（最终一致性）全局表在各处接受并发写入，并事后以后写者胜出进行调和。MRSC 全局表做出相反的权衡：一次写入必须在被确认之前跨区域协调，因此两个区域在同一时刻修改同一个项目是一个真正的冲突——其中一方会得到这个异常，而不是一次静默覆盖。

为什么会发生

同一个项目从多个区域并发写入——两个应用部署都把该项目当作自己该更新的。
一个热点协调项目——计数器、锁或被每个区域触及的单例配置项目是天然的冲突磁石。
跨区域的重试风暴——来自不同区域的同一逻辑操作的同时重试不断重新碰撞。

如何修复

用指数退避加抖动重试——冲突是短暂的；一旦另一个区域的写入完成，重试就会进行。AWS 把这个错误标记为可重试：

// let the SDK's adaptive retry handle it, or catch and back off:
catch (e) {
  if (e.name === 'ReplicatedWriteConflictException') return retryWithBackoff(op);
  throw e;
}

给项目一个归属区域——把某个键的写入通过一个区域路由（按用户驻留地、租户或分区），让其他区域以读为主。当只有一个区域改动一个项目时，争用就消失了。
让并发更新可交换——在不同属性上的原子计数器更新（ADD / SET x = x + :n）比对整个项目的读-改-写循环更少冲突。
输掉竞速后重新检查意图——另一个区域改动了该项目；一次条件重试（在一个版本属性上的 ConditionExpression）确保你的写入相对新状态仍然有效。

当数据摆在你眼前时，观察一个项目跨区域的变化会容易得多——DynoTable 桌面应用连接到每个副本区域，让你能并排比较项目，而 DynamoDB 定价计算器会估算复制写入的成本。

在 DynoTable 中检查

冲突后跨 Region 比较相同的项目 — 使用 ⌘P 切换，使用 ⌘K 打开表，并排读取每个副本 Region 中的项目。暂存 (⌘S) 允许你准备条件重试并在提交之前检查差异。在热表上启用 MRSC 之前，使用 pricing calculator 估算复制写入成本。在“设置”→“配置文件”下使用 Test Connection 配置每个区域。参见连接 AWS和安装。

来源

How DynamoDB global tables work（2026-07-13 验证）
Error handling with DynamoDB（2026-07-13 验证）

参考资料

最后核实于 2026-07-13，依据上方链接的 AWS 官方文档。

ReplicatedWriteConflictException

含义

为什么会发生

如何修复

在 DynoTable 中检查

来源

相关错误

参考资料