DynamoDB transactWrite跨多表不具备ACID？事务取消后部分操作仍写入

DynamoDB的transactWriteItems（即你使用的跨表事务接口）严格符合ACID原子性要求，不存在跨多表执行时部分操作提交、部分回滚的机制设计缺陷。你观察到的“失败事务中前两个Put已写入”的现象，属于排查过程中的认知偏差，并非事务本身不具备原子性。

你收到的异常返回中，取消原因数组与TransactItems的操作顺序一一匹配：

• 前两个标识None，代表对dev-table的两个Put操作在事务前置校验阶段，未检测到条件不满足、参数错误等问题，本身具备执行条件
• 最后一个标识TransactionConflict，代表对dev-table-metadata表的Update操作，在事务两阶段提交的锁校验环节，检测到对应分区被其他未完成的事务持有排他锁，无法获取写权限

按照DynamoDB事务的运行规则，只要任意一个参与事务的操作无法通过校验、拿不到分区排他锁，整个事务会直接终止，不会有任何操作进入实际落盘环节，不存在部分提交的可能。

结合你给出的请求参数、10次循环触发请求的场景，这类误判基本来自两个场景：

• 写入数据未做请求级唯一隔离：你给出的两个Put操作的写入内容是完全固定的ref=0,date=0、ref=1,date=0，没有给每次循环的请求增加可区分的唯一标识。你在dev-table里看到的两条固定数据，大概率是之前某一次成功执行的事务写入的，并非这次触发TransactionConflict的失败请求写入——失败请求从始至终就没有提交任何写入。
• 读取数据使用最终一致性模式：DynamoDB默认的读请求采用最终一致性策略，如果在事务失败后立刻用默认配置读表，很可能读到数秒前某个已成功提交的事务的残留数据，误导你把之前成功请求的写入结果，算到这次失败的事务头上。

• 验证回滚逻辑有效性：给每次循环的Put Item增加全局唯一的requestId字段（比如随机生成的UUID），当再次触发TransactionConflict异常时，带着这个requestId查询dev-table的对应记录，会发现记录根本不存在，即可证明全量回滚是完全生效的。
• 降低TransactionConflict触发概率：你10次循环的请求全部对dev-table-metadata表里主键为refConsumed的同一个键做更新，该键对应的分区是典型热点，多个并发事务同时争抢这个键的排他锁就会触发冲突。可以通过SDK内置的指数退避重试机制处理瞬时冲突，也可以把单热点键拆成多个子键分散写入压力，从根源降低冲突概率。
• 排查时统一使用强一致性读：在读表请求中开启ConsistentRead=true，避免读到过期的已提交数据，干扰问题定位。

内容的提问来源于stack exchange，提问作者saurabh_garg