# 3. 超过账户限额
按需表没有预置容量级别可供管理，但是 DynamoDB 会强制执行账户级别的吞吐量限制，以防止执行失控并确保所有客户公平使用资源。这些每个表的账户限额作为可调整的保障措施，可以针对各个账户与区域的组合来设定。当您的读取或写入消耗速率超过这些限额时，DynamoDB 会在节流异常中返回 `AccountLimitExceeded` 节流原因类型。当表没有配置自定义的最大吞吐量设置时，会自动应用默认的每个表的账户限额。您可以选择配置最大吞吐量设置，来更精细地控制成本，实现更好的可预测性；如果您的应用程序的需求超过默认限额，则可通过 [Amazon DynamoDB 中的配额](ServiceQuotas.md) 控制台请求增加配额。
## 账户超出限额的缓解措施
本节针对账户限额节流场景提供解决方法指导。使用本指南之前，请确保您根据应用程序的异常处理确定了具体的节流原因，并确定了受影响资源的 Amazon 资源名称（ARN）。有关检索节流原因和识别受限制资源的信息，请参阅[DynamoDB 节流诊断框架](throttling-diagnosing-workflow.md#throttling-diagnosing)。
在深入研究具体的节流场景之前，请先确定是否确实需要采取行动：
+ **评估性能影响**：检查在出现节流情况时，您的应用程序是否仍能满足性能要求。许多应用程序可在达到或接近账户限额的情况下成功运行，尤其是在批量操作或数据迁移期间。
+ **查看节流模式**：如果节流是间歇性的，并且应用程序可以有效地处理重试，则当前限额可能足以满足您的工作负载。
如果您的应用程序即便在偶尔达到账户限额时，性能也可以接受，则您可以选择仅仅对情况进行监控，而不是立即实施更改。
如果您确定节流导致了不可接受的性能问题或可靠性问题，请在下面选择特定的节流原因来查找推荐的缓解选项：
+ [TableReadAccountLimitExceeded](#throttling-table-read-account-limit)
+ [TableWriteAccountLimitExceeded](#throttling-table-write-account-limit)
+ [IndexReadAccountLimitExceeded](#throttling-index-read-account-limit)
+ [IndexWriteAccountLimitExceeded](#throttling-index-write-account-limit)
### TableReadAccountLimitExceeded
**何时出现**
表的读取消耗量，超过了所在区域的账户级别每个表的读取吞吐量配额。您可以在 [常见的诊断和监控方法](#account-limit-exceeded-diagnosis-monitoring) 中监控 CloudWatch 指标来分析节流事件。
**解决方法**
按照以下步骤解决此节流问题：
+ **请求提高限额**：
请求提高每个表的读取吞吐量限额（配额代码 L-CF0CBE56）。有关如何提交请求的详细步骤，请参阅[请求增加每个表的配额](#account-limit-request-per-table-quota)。
### TableWriteAccountLimitExceeded
**何时出现**
表的写入消耗量，超过了所在区域的账户级别每个表的写入吞吐量配额。您可以在 [常见的诊断和监控方法](#account-limit-exceeded-diagnosis-monitoring) 中监控 CloudWatch 指标来分析节流事件。
**解决方法**
按照以下步骤解决此节流问题：
+ **请求增加配额**：请求增加每个表的写入吞吐量限额（配额代码 L-AB614373）。有关如何提交请求的详细步骤，请参阅[请求增加每个表的配额](#account-limit-request-per-table-quota)。
### IndexReadAccountLimitExceeded
**何时出现**
指向全局二级索引（GSI）的读取操作消耗的吞吐量，超过当前 AWS 区域中您的账户的每个表的读取配额所允许的吞吐量。账户级别每个表的读取吞吐量配额，是表及其所有 GSI 的吞吐量总和。您可以在 [常见的诊断和监控方法](#account-limit-exceeded-diagnosis-monitoring) 中监控 CloudWatch 指标来分析节流事件。
**解决方法**
根据账户的容量分布选择合适的解决方法：
+ **请求增加配额**：请求增加每个表的读取吞吐量限额（配额代码 L-CF0CBE56）。有关如何提交请求的详细步骤，请参阅[请求增加每个表的配额](#account-limit-request-per-table-quota)。
+ **优化 GSI 使用情况**：[查看 GSI 设计和查询模式](#account-limit-optimize-gsi-projections)，减少不必要的读取容量消耗。
### IndexWriteAccountLimitExceeded
**何时出现**
对基表的写入操作生成了对 GSI 的相应更新，这些更新的总和超过了 AWS 区域账户级别每个表的写入吞吐量配额。当基表项目包含通过某个 GSI 编制索引的属性时，对基表项目的每个写入操作就会触发对该 GSI 的相应写入操作。这些写入操作总和计入每个表的写入吞吐量配额。您可以监控 [常见的诊断和监控方法](#account-limit-exceeded-diagnosis-monitoring) 中的 CloudWatch 指标，来分析这些节流事件的模式和时机，并确定哪些操作导致了 GSI 写入活动过多。
**解决方法**
根据账户的容量分布选择合适的解决方法：
+ **请求增加配额**：请求增加[每个表的写入吞吐量限额](#account-limit-request-per-table-quota)（配额代码 L-AB614373），以适应来自基表操作的更高 GSI 写入流量。每个表的写入吞吐量配额应用到整个表，包括其所有 GSI。有关如何提交请求的详细步骤，请参阅[请求增加每个表的配额](#account-limit-request-per-table-quota)。
+ **优化 GSI 投影**：[检查 GSI 投影和设计](#account-limit-optimize-gsi-projections)，来减少对 GSI 的写入量。
## 常见的诊断和监控方法
在对超出账户限额导致的节流事件进行故障排除时，您可以通过多个 CloudWatch 指标来确定是达到每个表还是账户级别的限制，以及了解您的容量分配模式。
**关键 CloudWatch 指标**
监控以下关键指标来诊断账户限额节流问题：
+ **账户限额节流事件**：[https://docs.aws.amazon.com//amazondynamodb/latest/developerguide/metrics-dimensions.html#ReadAccountLimitThrottleEvents](https://docs.aws.amazon.com//amazondynamodb/latest/developerguide/metrics-dimensions.html#ReadAccountLimitThrottleEvents) 和 [https://docs.aws.amazon.com//amazondynamodb/latest/developerguide/metrics-dimensions.html#WriteAccountLimitThrottleEvents](https://docs.aws.amazon.com//amazondynamodb/latest/developerguide/metrics-dimensions.html#WriteAccountLimitThrottleEvents) 跟踪什么时候由于超出账户级别限额导致请求受限。[https://docs.aws.amazon.com//amazondynamodb/latest/developerguide/metrics-dimensions.html#ReadThrottleEvents](https://docs.aws.amazon.com//amazondynamodb/latest/developerguide/metrics-dimensions.html#ReadThrottleEvents) 和 [https://docs.aws.amazon.com//amazondynamodb/latest/developerguide/metrics-dimensions.html#WriteThrottleEvents](https://docs.aws.amazon.com//amazondynamodb/latest/developerguide/metrics-dimensions.html#WriteThrottleEvents) 跟踪什么时候读取或写入请求超出了预置容量。
+ **按资源划分的容量消耗[：每个表和 GSI 的 `ConsumedReadCapacityUnits`](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/metrics-dimensions.html#ConsumedReadCapacityUnits)** 和 [https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/metrics-dimensions.html#ConsumedWriteCapacityUnits](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/metrics-dimensions.html#ConsumedWriteCapacityUnits) 显示各自的资源使用情况。
+ **账户级别的消耗**：使用 CloudWatch 指标数学表达式对所有表和 GSI 使用的容量求和，来监控账户的总使用量。
## 解决过程
### 请求增加每个表的配额
如果应用程序需要在超出当前每个表的吞吐量限额的情况下运行，您应使用以下步骤提交增加配额的请求。在一个特定区域中，您的 AWS 账户中的每个 DynamoDB 表（及其所有关联的 GSI）都受这些吞吐量配额的约束。这些配额表示任何单个表及其 GSI 总共可以使用的最大读取或写入容量，配额独立应用于每个表，而不是作为账户中所有表的容量总和。
或者，您也可以通过按照每个表或每个 GSI 配置最大按需吞吐量设置，来设置较低的限额。
1. 确定需要增加的具体配额：
+ **每个表的读取吞吐量限额**（配额代码 L-CF0CBE56）：每个表默认 40000 个 RCU
+ **每个表的写入吞吐量限额**（配额代码 L-AB614373）：每个表默认 40000 个 WCU
1. 使用 [AWS Service Quotas 控制台](https://docs.aws.amazon.com/servicequotas/latest/userguide/intro.html)请求增加配额：
+ 在 Service Quotas 中导航到 DynamoDB 服务
+ 使用配额代码查找相应的配额
+ 根据您的预计峰值使用量申请增加配额
1. 提供增加配额的理由，包括：
+ 当前的使用模式和峰值流量需求
+ 增加容量的业务理由
+ 何时需要增加容量的时间表
**注意**
配额增加的处理通常需要 24-48 小时。请相应地计划您的请求，并在等待批准时考虑采取临时的缓解策略。
### 优化 GSI 投影和设计
优化全局二级索引（GSI）投影和设计，来减少容量消耗并提高性能。
**选择性投影策略**
如果您的查询只需要访问几个属性，则只投影这几个属性，这样在基表项目发生更改时，可以减少写入 GSI 的数据量。有关投影类型的详细信息，请参阅[全局二级索引的投影](https://docs.aws.amazon.com//amazondynamodb/latest/developerguide/GSI.html#GSI.Projections)。
1. 分析查询模式：检查应用程序的查询模式，确定哪些属性实际上是通过 GSI 访问的。
1. 使用选择性投影：仅投影查询中实际需要的属性，从而减少写入量。
1. 考虑使用 `KEYS_ONLY`：如果查询只需要关键属性，请使用 `KEYS_ONLY` 投影来尽可能减少写入量。
1. 平衡读取与写入的权衡：对较少的属性进行投影可以减少写入容量消耗，但可能需要额外的基表读取。
**稀疏 GSI 实施**
稀疏 GSI 仅包含已编制索引的属性的项目，而不是基表中的所有项目。当您经常查询特定数据子集时，这可以减少分区密度并提高性能。
1. 设计仅包含具有特定属性值的项目的 GSI。
1. 通过仅在应编制索引的项目上设置 GSI 分区键属性，来实施条件索引。
1. 在稀疏 GSI 中使用复合键（例如 status\$1timestamp），进一步在编制了索引的项目子集中分配流量。
有关实施这些策略的更多信息，请参阅[在 DynamoDB 中使用二级索引的最佳实践](https://docs.aws.amazon.com//amazondynamodb/latest/developerguide/bp-indexes.html)。