ReplicatedWriteConflictException

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

含义

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

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

为什么会发生

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

如何修复

1. 用指数退避加抖动重试——冲突是短暂的；一旦另一个区域的写入完成，重试就会进行。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;
   }

2. 给项目一个归属区域——把某个键的写入通过一个区域路由（按用户驻留地、租户或分区），让其他区域以读为主。当只有一个区域改动一个项目时，争用就消失了。

3. 让并发更新可交换——在不同属性上的原子计数器更新（ADD / SET x = x + :n）比对整个项目的读-改-写循环更少冲突。

4. 输掉竞速后重新检查意图——另一个区域改动了该项目；一次条件重试（在一个版本属性上的 ConditionExpression）确保你的写入相对新状态仍然有效。

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

相关错误

• TransactionConflictException——单区域的表亲：一个进行中的事务占有该项目。
• Global table version mismatch
• ReplicaAlreadyExistsException
• 学习：DynamoDB global tables

References

• Error handling with DynamoDB — Amazon DynamoDB Developer Guide
• How DynamoDB global tables work — Amazon DynamoDB Developer Guide
• PutItem — Amazon DynamoDB API Reference

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