DynamoDB触发节流错误后RCU/WCU未增长如何确认容量调整状态

你遇到的节流是On-demand容量模式的正常机制：新创建的表、全局二级索引（GSI），或是长期处于低负载的表/GSI，初始默认承载的吞吐量有上限，当短时间流量突增超过该上限时，DynamoDB会自动在后台触发吞吐量扩容，扩容未完成期间的请求会返回你看到的ThrottlingException，扩容过程通常持续1-5分钟，流量涨幅过大时可能分多轮完成。

可通过以下3种方式准确确认表和GSI的容量调整进度：

• 控制台状态核查
  进入DynamoDB对应表的详情页：
  1. 查看概览页的表状态，若显示Updating代表表本身正在进行配置调整
  2. 切换到「索引」标签页，找到对应报错的GSI，若索引状态显示Updating代表该索引仍在扩容流程中；只有表和目标GSI的状态均显示为Active时，才代表本次容量调整全部完成。
• 接口/CLI状态查询（最准确，无监控延迟）
  直接调用DynamoDB的DescribeTable接口，或执行CLI命令：

  aws dynamodb describe-table --table-name <你的目标表名>
  

  解析返回结果：
  • 根字段TableStatus值为ACTIVE代表表本身状态正常
  • GlobalSecondaryIndexes数组下，对应目标GSI的IndexStatus字段值为ACTIVE，代表该GSI扩容完成
  • 任意上述状态字段返回UPDATING，都代表容量调整仍在进行中。
• CloudWatch指标核查（解决查不到指标的问题）
  查不到相关指标通常是维度或指标选择错误，按以下规则排查：
  1. 不要选择预留容量模式相关的ProvisionedReadCapacityUnits类指标，On-demand模式无预留容量相关的配额展示
  2. 选择指标时必须同时指定两个维度：TableName为你的目标表名，GlobalSecondaryIndexName为报错的GSI名称
  3. 重点关注两个指标：
     • ThrottledRequests：该指标计数降到0且持续1分钟以上无新增，代表当前容量已经可以承载现有请求
     • ConsumedReadCapacityUnits/ConsumedWriteCapacityUnits：如果消耗吞吐量的峰值不再被压平在固定阈值，而是随请求量正常上涨，代表扩容已经生效
       注意CloudWatch指标默认有1-3分钟的上报延迟，触发节流后不要立刻查询，等待3分钟以上再查看数据才准确。

注意事项：On-demand模式单轮扩容最多支持将吞吐量提升到之前30分钟峰值的2倍，如果你的流量涨幅远超过该阈值，会触发多轮顺序扩容，此时建议在请求端配置指数退避重试逻辑，避免高频无间隔请求拉长扩容周期。

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