使用PartiQL批量更新DynamoDB时遇写入容量超限问题求助

我用Python编写的Lambda函数通过PartiQL更新DynamoDB现有条目，配置如下：

• 每批更新5条记录
• 使用botocore标准重试模式（最多5次尝试）：

from botocore.config import Config

config = Config(
   retries = {
    'max_attempts': 5,
    'mode': 'standard'
  }
 )

• 批次之间添加20ms至60ms的随机休眠时间
• 每次Lambda执行最多处理200条记录

尽管做了以上配置，仍偶尔收到错误：

The level of configured provisioned throughput for the table was exceeded. Consider increasing your provisioning level with the UpdateTable API.

但查看DynamoDB监控面板时，写入使用率远低于预留配置（截图如下）：

请问该如何解决这个问题？

• 核查单条PartiQL更新的WCU消耗：PartiQL的UPDATE语句如果涉及非主键查询条件、读取旧值（如使用RETURNING OLD）或复杂表达式，实际消耗的写容量单位（WCU）可能高于1条=1WCU的预期。可通过DynamoDB的容量计算器估算单条操作的实际消耗，确保批量请求的总WCU在预留范围内。
• 切换自适应重试模式：标准重试模式的指数退避可能导致多批次并发重试，短时间内形成请求峰值。将重试模式改为adaptive，它会根据服务端返回的错误信号动态调整重试频率和并发量，减少突发流量：

config = Config(
   retries = {
    'max_attempts': 5,
    'mode': 'adaptive'
  }
 )

• 排查热点键问题：如果更新的条目集中在同一个分区键，即使表的整体WCU未耗尽，单个分区的吞吐量上限（表总WCU/分区数）也可能被突破。检查更新数据的分区键分布，若存在热点，需调整数据模型（如添加随机后缀、使用复合分区键）分散请求。
• 启用细粒度监控：DynamoDB默认分钟级监控会平均掉瞬间峰值，导致看起来使用率低但实际某一秒超量。开启CloudWatch的1秒级细粒度监控，或在Lambda中记录每次请求的时间戳和响应中的消耗指标，定位瞬间流量峰值。
• 优化休眠与速率控制：当前20-60ms的休眠可能不足以抵消多Lambda实例并发的请求叠加。可提高休眠时间上限（如至100ms），或根据前一次请求的延迟/错误动态调整休眠时长；也可使用SQS作为请求缓冲，通过设置队列的可见性超时和批量大小，平滑控制DynamoDB的请求速率。
• 检查Lambda并发数：若多个Lambda实例同时运行，每个实例处理200条记录的批量请求，总请求量可能瞬间超过表的WCU。可调整Lambda的并发执行限制，或使用事件源映射的批处理参数（如减少每次触发的记录数），降低并发请求压力。

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