解决 Amazon DynamoDB 中的延迟问题 - Amazon DynamoDB
Amazon Web Services 文档中描述的 Amazon Web Services 服务或功能可能因区域而异。要查看适用于中国区域的差异，请参阅 中国的 Amazon Web Services 服务入门 (PDF)。

解决 Amazon DynamoDB 中的延迟问题

如果您的工作负载出现高延迟，您可以分析 CloudWatch SuccessfulRequestLatency 指标，并检查平均延迟，看看是否与 DynamoDB 有关。报告的 SuccessfulRequestLatency 中的一些变化是正常的，偶尔的峰值（尤其是 Maximum 统计数据中的峰值）不用担心。但是，如果 Average 统计数据显示急剧增加并且持续存在，则应查看 Amazon 服务运行状况控制面板和您的 Personal Health Dashboard 来了解更多信息。一些可能的原因包括表中项目的大小（1 KB 的项目和 400 KB 的项目延迟会有所不同）或查询的大小（10 个项目与 100 个项目会有不同）。

如有必要，可以考虑向 Amazon Web Services Support 提交支持案例，并根据您的运行手册继续评估应用程序的任何可用回退选项（例如，如果您使用多区域架构，则撤出区域）。您应该记录缓慢请求的请求 ID，以便在提交支持案例时，向 Amazon Web Services Support 提供这些 ID。

该 SuccessfulRequestLatency 指标仅衡量 DynamoDB 服务内部的延迟，不包括客户端活动和网络往返时间。要详细了解从您的客户端调用 DynamoDB 服务的总体延迟，您可以在 Amazon SDK 中启用延迟指标日志记录。

注意

对于大多数单例操作（通过完全指定主键值来应用于单个项目的操作），DynamoDB 提供个位数毫秒级 Average SuccessfulRequestLatency。此值不包括访问 DynamoDB 端点的调用方代码的传输开销。对于多项目数据操作，根据结果集的大小、返回的数据结构的复杂性以及应用的任何条件表达式和筛选条件表达式等因素，延迟将会有所差异。对于使用相同参数对同一数据集重复执行的多项目操作，DynamoDB 将提供高度一致的 Average SuccessfulRequestLatency。

考虑以下一种或多种策略来减少延迟：

  • 调整请求超时和重试行为：从您的客户端到 DynamoDB 的路径遍历许多组件，每个组件的设计均考虑了冗余。想想网络弹性的范围、TCP 数据包超时以及 DynamoDB 本身的分布式架构。默认 SDK 行为旨在为大多数应用程序找到适当的平衡。如果最佳延迟是您的最高优先级，则应考虑调整 SDK 的默认请求超时和重试设置，以密切跟踪客户端衡量的成功请求的一般延迟。花费时间比正常时间长很多的请求最终成功的可能性较小 - 如果您很快失败并提出新的请求，很可能会采取不同方式并且可能很快就会成功。请记住，在这些设置中过于激进可能会带来不利影响。有关此主题的有用讨论可以在调整延迟感知型 Amazon DynamoDB 应用程序的 Amazon Java SDK HTTP 请求设置中找到。

  • 缩短客户端与 DynamoDB 端点之间的距离：如果您的用户分布在全球，请考虑使用全局表 - DynamoDB 的多区域复制。使用全局表，您可以指定希望表可用的 Amazon 区域。从本地全局表副本读取数据可以显著减少用户的延迟。此外，还可以考虑使用 DynamoDB 网关端点将您的客户端流量保持在 VPC 内。

  • 使用缓存：如果您的流量读取量很大，请考虑使用缓存服务，例如 利用 DynamoDB Accelerator（DAX）实现内存中加速。DAX 是用于 DynamoDB 的完全托管式高可用内存中缓存，可提高 10 倍性能（从毫秒到微秒），即使每秒数百万次请求也是如此。

  • 重用连接：DynamoDB 请求通过经过身份验证的会话（默认为 HTTPS）发出。启动连接需要时间，因此第一个请求的延迟高于一般延迟。通过已初始化的连接发出的请求可提供 DynamoDB 的一致低延迟。因此，如果没有发出其他请求，您可能希望每 30 秒发一次 “保持活动”GetItem 请求，以避免建立新连接的延迟。

  • 使用最终一致性读取：如果您的应用程序不需要强一致性读取，请考虑使用默认的最终一致性读取。最终一致性读取的成本较低，而且延迟出现临时增加的可能性也较小。有关更多信息，请参阅 读取一致性。