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