了解 DynamoDB 中的全局二级索引（GSI）写入节流和背压
GSI 背压节流是 DynamoDB 中最复杂的节流场景之一，因为这种情况在写入操作和节流之间建立的是间接的关系，即您的应用程序写入基表，但由于一个或多个索引的容量限制导致出现节流情况。
了解 GSI 背压节流
在您写入 DynamoDB 表时，该表的所有全局二级索引（GSI）都会使用最终一致性模型异步更新。如果 GSI 没有足够的容量来处理这些更新，DynamoDB 会限制对基表的写入来维护数据一致性。这种情况称为 GSI 背压。有关 GSI 工作方式的更多信息，请参阅 DynamoDB 中的全局二级索引。
在直接的表节流时，所访问的资源也就是造成节流的资源，而 GSI 背压则不同，背压会在基表与其索引之间造成依赖关系。即使您的基表有充足的容量，如果任何关联的 GSI 无法处理更新量，则写入也会受限。了解这种关系尤其重要，因为分区级别的约束独立应用到基表和每个 GSI，每个 GSI 都有各自的分区结构和对应的吞吐量限额。
GSI 分区基于 GSI 的分区键，分区键通常不同于基表的分区键。即使您的基表访问非常均匀地分布在各个分区上，GSI 更新也可能仍会集中在特定的分区上，从而在 GSI 中造成热点。有关表和 GSI 的分区键设计的一般最佳实践，请参阅 DynamoDB 分区键设计。
例如，如果您的基表使用 customerId 作为分区键（均匀分布），而您的 GSI 使用 status 作为分区键（可能的值有限，例如“active”、“pending”、“closed”），则即使基表访问平衡，但对具有常用状态值的项目进行更新也可能会造成 GSI 热分区。这就造成了一个特别具有挑战性的场景，即应用程序可能会因为 GSI 热分区而遇到节流情况，但基表和 GSI 都有足够的总体容量，并且基表的访问模式看起来分布是均匀的。
尽管节流异常指向 GSI（通过 ResourceArn），但实际受限制的操作是对基表的写入。这可能会造成困惑，因为应用程序在写入基表，但收到与 GSI 相关的异常。
GSI 节流的类型
根据具体的容量约束，GSI 背压节流会通过不同的异常类型表现出来：
-
超过 GSI 预置容量：当 GSI 没有足够的写入容量单位，无法处理来自基表操作的更新时，就会发生这种情况。这会生成
ProvisionedThroughputExceededException以及原因 IndexWriteProvisionedThroughputExceeded，并且ResourceArn直接指向遇到容量约束的特定 GSI。 -
超出 GSI 按需最大吞吐量：当 GSI 写入操作超过按需表上配置的最大限制时，就会发生这种情况。这会生成
ThrottlingException以及原因 IndexWriteMaxOnDemandThroughputExceeded，标识配置了吞吐量限制的特定 GSI。 -
超出 GSI 分区限额：当单独的 GSI 分区超过其吞吐量限制（热分区）时，即使 GSI 的总体容量仍然充足，也会发生这种情况。这会生成
ThrottlingException以及原因 IndexWriteKeyRangeThroughputExceeded，表明ResourceArn中标识的特定 GSI 存在热分区问题。这一点尤其重要，因为 GSI 分区分布可能与基表的分区分布存在显著差异，造成了虽然基表访问分布均匀，但在 GSI 中产生热点的情况。 -
超出 GSI 账户限额：在账户级别设置了每个表（或者该表中的任意单个 GSI）的区域吞吐量界限，当对特定 GSI 的写入操作超过了界限时，就会触发此问题。DynamoDB 返回
ThrottlingException以及原因 IndexWriteAccountLimitExceeded，指向导致使用量超出账户限额的 GSI。每个超过限额的 GSI 出现的这种节流情况是独立的。有关每个表、每个账户、区域、服务配额的信息，请参阅 Amazon DynamoDB 中的配额。