DynamoDB批量操作返回未处理项但实际已处理问题咨询

我正在实现一个高吞吐量解决方案，单实例每秒处理500-700条数据，采用DynamoDB做持久化存储。每条数据至少执行2次写入和1次读取，流程如下：

• 收到A-1类数据，写入DynamoDB；
• 收到需与A-1配对的B-1类数据，通过两者共享的主键查找A-1；
• 若找到A-1和B-1，完成配对及业务逻辑后，更新A-1标记为已处理或删除A-1以避免重复处理。

为提升性能，我采用批量读写/删除操作，流程为：

• 尝试批量更新/删除整个批次；
• 获取未处理项列表并逐个处理；
• 再次获取逐个处理仍失败的项；
• 返回最终未处理项列表（例：批次含A-1、A-2、A-3、A-4，批量处理后A-2、A-3为未处理项，单独处理后A-3成功、A-2失败，最终返回A-2）；
• 不对未处理项执行业务操作。

在200万条A类数据+200万条B类数据的性能测试中，发现部分被标记为未处理的项实际已被更新或删除。因防重复处理机制，这些项未执行业务逻辑，最终缺失在结果中。

请问：DynamoDB是否会出现返回未处理但实际已处理的情况？若会，该场景下有何应对建议？

一、DynamoDB确实存在返回未处理但实际已处理的情况 #

这种现象主要发生在BatchWriteItem、BatchDeleteItem这类批量操作中，核心原因包括：

• 网络传输异常：DynamoDB服务端已成功执行操作，但响应在传输过程中丢失或超时，导致客户端收到"未处理"的反馈；
• 幂等性冲突：客户端重试批量请求时，部分项可能已被前一次请求处理，但批量响应仍将其标记为未处理；
• 服务端内部重试：DynamoDB对部分操作进行内部重试后，客户端收到的响应未同步最新的处理状态。

二、针对性应对建议 #

1. 强制操作幂等性

   • 为每个更新/删除操作添加唯一的IdempotencyToken参数，确保重复执行操作不会改变业务状态；
   • 更新操作使用条件表达式（如ConditionExpression: "processed = :false"），仅当目标项未被处理时才执行更新，从根源避免重复处理。

2. 优化未处理项的校验逻辑

   • 对批量操作返回的未处理项，不要直接判定为失败，而是通过GetItem主动查询该项的实际状态；
   • 根据查询结果调整流程：若状态显示已处理，则跳过该项；若确实未处理，再执行单条操作。

3. 调整批量操作的重试策略

   • 对未处理项采用分级处理：先尝试小批量重试，再降级为单条操作，避免因大批次重试加剧服务端负载；
   • 重试时添加短暂延迟（如100-200ms），降低重复请求的冲突概率。

4. 重构去重机制

   • 不要仅依赖DynamoDB的项状态判断是否执行业务逻辑，单独维护一个业务结果存储表，记录已完成配对的主键；
   • 处理B类数据时，先查询业务结果存储表，确认主键未完成配对后，再执行后续的查找和更新操作。

5. 改用事务操作替代批量操作

   • 若业务逻辑允许，使用TransactWriteItems替代批量操作，确保一组操作要么全部成功，要么全部失败，消除部分处理的模糊状态；
   • 事务操作提供更强的一致性保障，能大幅减少"已处理但返回未处理"的概率。

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