DynamoDB超出配置容量&强一致性读取失效问题求助

DynamoDB问题排查与解惑 #

一、部分表BatchWrite后容量突增两倍的排查方向 #

• 批量条目数差异：DynamoDB的WCU按单条写入请求计数，若这两张表的entities每次传入的条目数是其他表的两倍，即便TPS是40，实际每秒写入请求数会翻倍（比如40TPS×2条/批=80请求/秒），直接突破50的最大WCU限制。检查这两张表的批量写入条目数是否异常。
• SDK自动重试：BatchWrite出现部分失败时，AWS SDK默认会重试未成功的条目。若这两张表写入失败率更高，重试会额外消耗WCU，导致总容量翻倍。执行ExecuteAsync()后检查返回的UnprocessedItems，确认是否存在大量未处理条目引发的重试。
• 索引额外开销：若这两张表配置了全局二级索引（GSI）或本地二级索引（LSI），写入主表时会同步写入索引，每个索引写入会额外占用WCU。比如主表写1条数据+1个GSI写入，相当于消耗2倍WCU。对比其他表的索引配置，确认差异。
• 突发峰值触发超额：自动扩缩容存在延迟，若测试工具的请求并非严格匀速40TPS，而是存在瞬间脉冲式峰值，这两张表可能刚好触发临时容量超额。查看CloudWatch的WriteCapacityUnits指标，确认是否有瞬间峰值。

二、强一致性读取仍返回404的原因解析 #

• 写入未完全成功：await ExecuteAsync()完成仅代表SDK发送了请求，不代表所有条目都已成功持久化。BatchWrite是非原子操作，部分条目可能写入失败（如主键冲突、容量不足），需检查返回的UnprocessedItems是否为空，确认主键为"42"的条目是否被成功写入。
• 主键类型不匹配：确认写入时主键字段的类型（如数字/字符串）与读取时传入的hash_key="42"完全一致。DynamoDB对类型严格区分，数字42和字符串"42"会被视为不同主键。
• 强一致性的边界：强一致性读取仅能获取已成功持久化的写入结果。极端情况下，跨AZ写入同步可能存在极短延迟，此时立即读取仍可能返回404。可在写入完成后检查UnprocessedItems为空，再执行读取操作，而非依赖延迟等待。

相关代码片段

C#批量写入实现：

public async Task BatchWriteAsync(IEnumerable<T> entities, DynamoDBOperationConfig dynamoDBOperationConfig)
{
        var result = context.CreateBatchWrite<T>(dynamoDBOperationConfig);
        result.AddPutItems(entities);
        await result.ExecuteAsync();            
}

Python强一致性读取代码：

customer = customers.get_item(hash_key="42", consistent_read=True)

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