AWS返现 DynamoDB 频繁引发 ProvisionedThroughputExceededException 限流排查
DynamoDB 频繁引发 ProvisionedThroughputExceededException 限流排查：先看哪里最容易出问题
很多团队遇到 DynamoDB 频繁引发 ProvisionedThroughputExceededException 限流排查 时，第一反应是“是不是读写容量不够”。实际做过排查后会发现，真正卡住的往往不是单一容量值，而是业务访问方式、分区热点、批量写入、重试风暴、账户配额和账单状态一起叠加出来的结果。想尽快止血，应该先判断是“真实容量不足”，还是“某几个分区被打爆”，再决定是加容量、改访问模式，还是调整 AWS 账号和支付状态。
先判断：这类限流到底是容量不够，还是访问方式有问题
遇到 ProvisionedThroughputExceededException，不要马上盲目加容量。实际项目里，常见情况通常分成几类：
- 单表整体压力上升：全表读写都在涨，业务高峰明显，确实接近预配置容量上限。
- 热点分区：总量看起来不大，但某个 partition key 被持续高频访问，导致局部限流。
- 批量写入冲击：导入、补数、定时任务一次性把请求打满。
- 重试过猛：应用侧没有做退避，限流后立刻重试，反而把压力放大。
- 容量配置和业务节奏不匹配：白天低、晚上高，或者活动期间突增，但表容量没跟上。
最先看的不是“报错次数”，而是这几个信号
- CloudWatch 里的 ConsumedReadCapacityUnits / ConsumedWriteCapacityUnits 是否长期贴近 Provisioned 值。
- 限流是否集中在少数 key 上，而不是全表均匀发生。
- 报错前后是否有批处理、重放、同步任务、流量活动。
- 应用日志里是否出现连续重试，且没有指数退避。
经验上，很多“容量不够”的表，真正的根因其实是热点 key 和错误重试；先改访问模式，往往比单纯加容量更快见效。
常见触发场景：哪些业务最容易把 DynamoDB 打到限流
下面这些场景，是实际部署里经常遇到的：
- 用户资料表按手机号、地区码、设备 ID 查询，某个热门维度被频繁查询，形成热点。
- 订单表按时间倒序写入，所有新订单都落在相同或相近的分区键模式上。
- 日志、事件、埋点补录：一次性历史回灌，写入突发很大。
- 定时任务批量扫描：Scan 比 Query 更容易把读流量打散到整个表，同时把读容量吃紧。
- 消息消费失败重放：队列积压后集中消费，瞬时写入暴涨。
如果你的业务属于这些类型，优先考虑结构调整
- 订单、流水、事件类数据，尽量避免让“时间”直接成为单一热点键。
- 高并发查询场景，确认是否能从 Scan 改成 Query 或按业务维度拆表。
- 补数和导入任务，尽量分批、分时、限速执行，不要一次性全量灌入。
排查顺序：从报错到定位，一步一步缩小范围
- 确认是读限流还是写限流：读写侧处理思路不同，先分清楚。
- 看表级指标：是否 Consumed 接近 Provisioned，是否频繁触顶。
- 看分区热点：请求是否集中到少数 key。
- 看请求模式：是否有 Scan、BatchWrite、批量导入、并发重试。
- 看客户端重试策略：有无指数退避、抖动、最大重试次数。
- 看账户和账单状态：是否存在支付失败、风控冻结、资源配额异常。
一个容易被忽略的点：CloudWatch 只能告诉你“被打满了”，不一定告诉你“为什么被打满”
很多团队只看表级别的读写指标，发现没超太多，就误以为不是容量问题。实际上，DynamoDB 的限流经常是局部热点导致的：全表平均值不高，但某个分区已经满了。这也是为什么只加整个表容量，有时效果并不明显。
解决方案：先止血，再优化，再谈成本控制
处理 ProvisionedThroughputExceededException，建议按下面顺序来：
1. 先做快速止血
- 给应用加指数退避 + 随机抖动，避免限流后瞬时重试。
- 对批量任务做限速，不要让导入、同步、补数和线上请求抢同一资源。
- AWS返现 短期内适当提高预配置容量，先把业务恢复。
AWS返现 2. 再改访问模式
- 把高频热点 key 拆散，例如引入随机后缀、分桶键、时间片键。
- 减少 Scan，能 Query 就不要全表扫。
- 对高并发写入做队列缓冲，避免瞬间直写。
- 把大对象拆到对象存储，表里只保留索引和元数据，减少无效读写。
3. 最后再算长期成本
很多企业在处理 DynamoDB 限流时，只盯着“加容量会不会贵”。但更实际的做法是比较两种成本：
- 持续加容量，换取简单稳定，但可能在低峰期浪费较多。
- 调整表设计和访问模式，前期花时间，后续容量更平稳。
如果业务波峰波谷明显，通常要同时评估是否切换容量模式、是否拆表、是否分离读写密集型场景，而不是只靠人工提容量硬顶。
账号购买、实名认证、企业认证、支付方式：为什么这些会影响限流处理
很多人排查限流时只盯技术层，实际上在 AWS 国际站上，账户状态也会影响你能不能顺利调容量、开工单、完成账单处理。尤其是海外业务部署、临时扩容、活动保障期，这些问题很常见。
| 事项 | 实际影响 | 常见风险 |
|---|---|---|
| 账号购买 | 影响权限归属、账单控制、后续提额和工单沟通 | 账号来源不清、无法稳定接管、历史风控记录不明 |
| 实名认证 / 企业认证 | 影响账单审核、信用额度、部分服务开通速度 | 资料不一致、主体不匹配、审核被反复要求补充 |
| 充值续费 / 支付方式 | 影响资源是否可持续运行，避免因扣款失败导致服务受限 | 信用卡拒付、账单过期、支付失败触发风控 |
| 风控审核 | 影响提额、资源创建、区域变更和账户稳定性 | 短时间内频繁改配置、异常登录、支付信息异常 |
| 资源限制 | 影响表、索引、并发、配额调整 | 以为“加容量就能解决”，结果卡在账户侧限制 |
企业用户更建议怎么做
- 尽量使用企业主体自建账号，不要把生产系统放在归属不清的账号里。
- 支付方式提前确认可用，避免高峰期因扣款失败影响容量调整。
- 如果有多区域部署，提前确认目标区域的资源配额和审批节奏。
- 高频变更前先确认账户没有风控异常，否则调容量、建索引、开新表都可能被卡住。
如果你的 DynamoDB 已经出现频繁限流，但账号又处在支付审核、企业认证未完成、或风控待处理状态，优先级应先处理账户可用性，否则技术方案可能落不了地。
常见错误：很多人不是不会排查，而是第一步就走偏了
- 错误 1：只会加容量。热点 key 没改，容量加再多也可能继续限流。
- 错误 2：把 Scan 当 Query 用。全表扫描在业务高峰特别容易拖垮读容量。
- 错误 3：重试没有退避。报错后立刻重发，等于自己给自己制造流量峰值。
- 错误 4：批处理和线上业务同一时段跑。夜间补数和白天流量叠加，限流会更明显。
- 错误 5：只看表，不看索引。有时候是 GSI 先顶不住，而不是主表。
- 错误 6：账单和支付没确认。以为是技术故障，结果是支付失败、信用额度不足或风控触发。
资源控制与成本控制：什么时候该加容量，什么时候该改方案
如果你的目标是稳定线上业务，不建议把“加容量”当作唯一手段。可以按下面思路判断：
适合先加容量的情况
- 业务流量增长是明确的，且增长曲线相对稳定。
- 限流主要出现在可预测高峰，比如固定活动、固定批处理窗口。
- 短期内没有时间改表结构，但需要先恢复服务。
适合先改方案的情况
- AWS返现 限流反复出现，且总量并不大，说明更像热点问题。
- 业务模型本身就有明显倾斜，比如单个租户、单个用户组、单个地区流量过高。
- 长期要控制成本，不希望靠持续扩容硬撑。
FAQ：排查 ProvisionedThroughputExceededException 时最常被问到的问题
Q1：报这个错，是不是一定要立刻把容量调高？
AWS返现 不一定。先判断是不是热点分区、批量任务、错误重试导致的。很多情况下，改请求模式比单纯提容量更有效。
Q2：为什么表级别看起来没满，还是频繁限流？
因为限流可能集中在少数分区或某个索引上，平均值不高不代表局部不满。
Q3：要不要把所有读写都改成更大的预留容量？
不建议直接这么做。先看业务峰值是否持续、是否可以分流、是否有批处理冲击，再决定容量模式和费用结构。
Q4：账号购买、企业认证和支付方式真的会影响排查吗？
AWS返现 会。技术上你可能已经找到原因，但如果账号处于支付审核、风控待处理、信用额度不足或主体资料不完整的状态，很多调整动作无法顺利执行。
Q5：企业做海外部署，最稳妥的准备顺序是什么？
先把账号主体、支付方式、认证资料、预算和资源配额确认好，再上线表结构和容量策略。这样出了限流问题，才能第一时间执行调整，而不是先被账户状态卡住。
结论：排查这类限流，别只盯着报错本身
面对 DynamoDB 频繁引发 ProvisionedThroughputExceededException 限流排查，真正有效的做法是按“业务流量、热点分区、重试策略、索引压力、账户和账单状态”五个层面一起看。短期先止血，长期再优化访问模型和成本结构。对于已经进入生产的海外业务，账号购买方式、实名认证、企业认证、支付方式和风控状态，也要纳入排查清单，否则技术方案可能设计得很好，但执行时却卡在账户侧。
