我们的应用程序中有一段时间的延迟与 DynamoDB 中的延迟直接相关，我们正试图找出导致该延迟的原因。
在此期间，表的消耗读取和消耗写入正常（远低于预置容量），并且限制请求的数量也是 0 或 1。唯一增加的是 SuccessRequestLatency。
高延迟发生在我们进行大量自动写入的期间。在我们的用例中，写入 dynamo 还包括一些读取（以获取任何现有记录）。但是，我们经常在同一时间段内写入相同数量的数据，而不会增加任何延迟。
在我们似乎已经提供了足够的读取容量的情况下，是否有任何方法可以了解导致成功请求延迟增加的原因？有什么方法可以诊断这组对 dynamodb 的写入导致的延迟？
【问题讨论】：
您可以通过检查 CloudWatch 中的 Get Latency 和 Put Latency 来深入挖掘。
正如您已经提到的，没有节流，并且您的写入也涉及一些读取，并且您在其他时间段的写入不会导致任何延迟，您应该检查 read 操作导致了这种情况。
检查SuccessfulRequestLatency 指标，同时包括Operation 维度。以GetItem 和BatchGetItem 开头。如果没有
帮助包括Scan 和Query。
【讨论】：
当 DynamoDB 对其一个存储节点进行内部故障转移时，有时会出现高请求延迟。
在 Dynamo 内部，每个存储分区都必须跨多个节点进行复制，以提供高水平的容错能力。有时，其中一个节点会出现故障，因此必须引入替换节点，这可能会导致部分受影响请求的延迟增加。
如果您的用例对延迟敏感，我从 AWS 获得的建议是使用短超时和快速重试（例如 100 毫秒）。据我了解，只有命中受影响节点的请求才会增加延迟，因此在重试一到两次后，您将命中不同的节点并获得成功的响应，而对整体延迟的影响最小。显然很难验证这一点，因为这不是您可以重现的场景！
如果您与 AWS 签订了支持合同，那么在发生此类事件时，最好从 AWS 控制台提交支持票证。他们通常能够深入了解实际发生的情况。
注意：如果您正在重试，请记住使用指数退避来降低限制风险。
【讨论】：