DynamoDB TransactionConflictException

TL;DR — 另一个事务已经在操作与你请求相同的项目，因此 DynamoDB 为保持隔离性拒绝了你的。它是瞬时的争用，而不是你数据中的 bug——用指数退避重试、让事务保持小巧，并减少对同一个热点项目的并发写入。

含义

TransactionConflictException: Transaction is ongoing for the item

DynamoDB 会把与进行中事务冲突的写入串行化。当一个普通的 PutItem、UpdateItem 或 DeleteItem 与一个包含同一个项目的进行中 TransactWriteItems 碰撞时，你就会遇到这个异常。DynamoDB 不阻塞，而是用 TransactionConflictException（HTTP 400）拒绝这个单项目写入。它可重试——一旦另一个事务提交或中止，冲突就消除。

注意与 TransactionCanceledException 的区别：当输掉的请求本身是一个 TransactWriteItems 或 TransactGetItems 时，DynamoDB 会转而取消那整个事务——你得到的是一个_取消_，其 CancellationReasons 携带 TransactionConflict 作为逐项目的原因代码，而不是这个异常。

为什么会发生

对同一个项目的并发写入——一个普通的 PutItem/UpdateItem 与一个触及该项目的进行中 TransactWriteItems 重叠。
两个共享一个项目的事务——两个 TransactWriteItems 请求同时包含同一个键；一个胜出，另一个以 TransactionConflict 原因代码被取消（表现为 TransactionCanceledException）。
一个在大量并发更新下的热点项目——例如一个共享计数器或一个每个请求都更新的单一聚合行。
长或大的事务持有项目足够久以致与其他写入者重叠。
一场重试风暴——没有退避的重试把更多并发尝试堆到同一个被争用的项目上。

如何修复

用指数退避 + 抖动重试。 这是主要的修复方法——冲突是瞬时的，在另一个事务稳定后消除。保留抖动，让重试不会重新同步成又一次碰撞。
让事务保持小巧和简短——每个 TransactWriteItems 更少的项目意味着更短的持有和更少的重叠。
减少热点项目上的争用——把一个热点计数器分片到多个项目上并聚合，或者当你不需要全有或全无语义时，用一个带普通 UpdateItem（ADD）的原子计数器代替事务。
如果可以避免，就不要对同一个项目并发地混用一个事务和一个普通写入——把两者都通过同一条路径路由。
监控 TransactionConflict CloudWatch 指标，看争用是否在上升以及在哪里。

当并发写入者就是你自己——你的应用在写同一张表的同时你在手工编辑项目——DynoTable 的暂存区会把你的手工编辑批量成一次由你一次性审阅并提交的事务性写入，而不是一连串相互重叠的单项目写入。

在 DynoTable 中检查

当并发编写者是你时，通过暂存 (⌘S) 进行批量手动编辑 - DynoTable 将它们作为一次审阅的写入提交，而不是重叠的单项更新流。使用 ⌘K 打开竞争项目并在重试之前检查实时状态。使用 pricing calculator 调整交易流量。使用 ⌘P 切换配置文件； 在“设置”→“配置文件”上测试连接。参见连接 AWS和安装。

来源

Amazon DynamoDB Transactions: How it works（2026-07-13 验证）
PutItem — Amazon DynamoDB API Reference（2026-07-13 验证）

常见问题

如何修复 DynamoDB 中的 TransactionConflictException？ 使用指数退避和抖动重试请求 - 冲突是与同一项目上的另一个正在进行的事务的短暂争用。还要保持事务较小，对热门项进行分片，并避免同时对同一项运行事务和纯写入。

TransactionConflictException 与 TransactionCanceledException 相同吗？ 否。TransactionConflictException 表示当前正在对该项目进行另一个事务操作。 TransactionCanceledException 表示整个事务被回滚；它的 CancellationReasons 解释了原因，交易冲突可能是这些原因之一。

参考资料

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