本文解析 dynamodb 中因流事件重复触发导致的 transactwriteitem 并发写入异常问题，阐明条件表达式在事务中无法跨项保证全局唯一性，并提供基于主键设计、条件写入增强及幂等令牌的完整解决方案。
本文解析 dynamodb 中因流事件重复触发导致的 transactwriteitem 并发写入异常问题，阐明条件表达式在事务中无法跨项保证全局唯一性，并提供基于主键设计、条件写入增强及幂等令牌的完整解决方案。
在使用 DynamoDB Streams 触发 Lambda 处理 Table A 新增记录时，您期望为每个 A 记录严格生成且仅生成两个关联项（一个 B#xxx 根记录 + 一个 Parent#<id>;Default 唯一父占位符）到 Table B。但实际观察到：当两条近乎同时的 Stream 事件被并行处理时，出现了 3 条记录（2 个 B#xxx + 1 个 Parent#...），这表明当前逻辑未能实现预期的幂等性。
根本原因在于：TransactWriteItem 的条件表达式（如 attribute_not_exists('hashKey')）仅对单个 Put 操作生效，且其原子性作用域是整个事务——但该条件仅检查目标项是否存在，并不阻止其他并发事务“同时通过检查”后各自写入。更关键的是，您的 bRootItem（B#xxx）完全无条件写入，而 bParentItem 的条件仅校验自身主键是否已存在。由于两个并发事务都发现 Parent#658;Default 尚未存在，于是均成功写入 bParentItem —— 但 DynamoDB 的最终一致性或条件竞争窗口可能导致其中一个事务的 bParentItem 写入成功，另一个失败（按预期），然而 bRootItem 却不受任何保护，因此两个事务各自创建了独立的 B#xxx 根项。
✅ 正确理解：TransactWriteItem 确保事务内所有操作要么全成功、要么全失败，但它不提供跨事务的分布式锁或全局唯一性强制机制。条件表达式是乐观并发控制（OCC），依赖“检查-执行”原子性，但在高并发下仍可能因时间窗口重叠而失效。
解决方案：从设计到实现的三层保障
1. 主键设计重构（推荐首选）
将 Parent#<id>;Default 作为事实上的业务主键，并将 B#root 记录与之强绑定，避免分离写入：
// 使用固定 hashKey + 复合 sortKey 实现一对多关系
Map<String, AttributeValue> rootItem = new HashMap<>();
rootItem.put("hashKey", new AttributeValue("Parent#8954;Default")); // 统一父键
rootItem.put("sortKey", new AttributeValue("B#root#" + UUID.randomUUID())); // 唯一子排序键
rootItem.put("name", new AttributeValue("Default"));
rootItem.put("parentValue", new AttributeValue("8954;Default"));
Map<String, AttributeValue> parentPlaceholder = new HashMap<>();
parentPlaceholder.put("hashKey", new AttributeValue("Parent#8954;Default"));
parentPlaceholder.put("sortKey", new AttributeValue("Parent#8954;Default")); // 自引用占位
// 事务内：先确保父占位存在（带条件），再写根记录（无需条件，因 sortKey 唯一）
Put putParent = new Put()
.withTableName("B")
.withItem(parentPlaceholder)
.withConditionExpression("attribute_not_exists(hashKey)"); // 仅检查 hashKey
Put putRoot = new Put()
.withTableName("B")
.withItem(rootItem);
TransactWriteItem transact1 = new TransactWriteItem().withPut(putParent);
TransactWriteItem transact2 = new TransactWriteItem().withPut(putRoot);
dynamoDB.transactWriteItems(new TransactWriteItemsRequest()
.withTransactItems(Arrays.asList(transact1, transact2)));✅ 优势：Parent#8954;Default 的 hashKey 全局唯一，首个事务创建成功后，后续并发事务在 putParent 步骤即失败（ConditionalCheckFailedException），整个事务回滚，putRoot 不会执行，天然幂等。
2. 引入幂等令牌（适用于无法重构主键场景）
在 Stream 事件中提取或生成稳定业务标识（如 A 表的 PK#SK 或 eventID），将其作为 bRootItem 的 sortKey 或额外属性，并在 bParentItem 条件中联合校验：
String idFromStream = "8954";
String eventId = "stream-event-abc123"; // 从 stream record 获取
String parentKey = "Parent#" + idFromStream + ";Default";
// bRootItem 包含 eventId，用于去重追踪（非主键，仅辅助）
rootItem.put("eventId", new AttributeValue(eventId));
// bParentItem 条件升级为：父项不存在 OR 存在但 eventId 已记录（需新增 eventId set 属性）
String conditionExpr = "attribute_not_exists(hashKey) OR " +
"contains(#eventIds, :eventId)";
Map<String, String> exprNames = Map.of("#eventIds", "processedEventIds");
Map<String, AttributeValue> exprValues = Map.of(
":eventId", new AttributeValue(eventId)
);
Put putParent = new Put()
.withTableName("B")
.withItem(parentItem)
.withConditionExpression(conditionExpr)
.withExpressionAttributeNames(exprNames)
.withExpressionAttributeValues(exprValues);⚠️ 注意：此方案需提前在 parentItem 中维护 processedEventIds: Set<String>，并在事务中用 ADD 更新（需 Update 而非 Put），复杂度略高。
3. 运维兜底：启用 Data Plane Logging
如仍存疑，务必开启 DynamoDB CloudTrail 数据平面日志，过滤 PutItem 和 TransactWriteItems 事件，按 hashKey 和时间戳分析调用来源（Lambda 执行 ID、IP 等），确认是否真为双流触发，或存在其他未知写入源。
总结
- ❌ 错误认知：TransactWriteItem 内的 Put 条件能阻止所有并发写入 → 实际只能防止同一事务内冲突，无法解决跨事务竞态。
- ✅ 正确实践：以业务唯一性维度（如 Parent#<id>;Default）作为 hashKey，利用 DynamoDB 主键强唯一性作为天然分布式锁，是最简洁、可靠、符合 NoSQL 设计哲学的解法。
- ? 最终建议：采用方案 1（主键重构），辅以 CloudTrail 日志验证；避免在事务中混合无条件写入与条件写入来模拟业务约束——应让数据模型本身承载一致性语义。
