了解亚马逊 DynamoDB 延迟

Amazon DynamoDB 使用水平扩展来支持几乎任何大小的表。除了水平扩展外，DynamoDB 还为各种规模的工作负载提供个位数毫秒的性能。像亚马逊这样的零售网站使用DynamoDB作为其购物车和工作流程引擎。处理订单时响应缓慢不仅会让客户感到沮丧，还可能是一个代价高昂的业务问题。订单处理的延迟可能会对收入、客户体验和业务增长产生直接影响。

在这篇文章中，我将深入探讨 DynamoDB 延迟以及在使用 DynamoDB 支持的应用程序时可用于处理高于正常延迟的技术。

什么是 DynamoDB 延迟？

DynamoDB API 延迟是将查询输入到 DynamoDB 基础架构与向用户交付响应之间的响应时间。延迟分为两类：服务端延迟和客户端延迟。

端到端延迟是一种分担责任模型，其中服务端延迟由 DynamoDB 服务负责，客户端延迟由用户负责针对其特定场景和环境正确配置客户端应用程序。

什么是服务端延迟？

服务端延迟是指从 API 请求到达 DynamoDB 的那一刻起，DynamoDB 处理请求所花费的时间，直到 DynamoDB 向用户应用程序发送回复。服务端延迟不包括应用程序连接到 DynamoDB 公共端点或从 DynamoDB 公共端点下载结果所花费的时间。

你可以使用 亚马逊 CloudWatch S u cessfulRequestLat ency 指标来分析这种类型的延迟。延迟偶尔出现峰值并不令人担忧；但是，最佳做法是在分析 Su ccessful RequestLatency 指标时检查平均延迟。如果平均延迟持续较高，则可能存在导致额外延迟的潜在问题。

如何处理高于正常水平的服务端延迟

使用 DynamoDB 的好处之一是它是一项完全托管的服务。这意味着您不必担心修补、安全性、复制、数据持久性、设置和扩展实例或备份和恢复等问题。同样，服务端延迟由 DynamoDB 负责监控和解决。如果您遇到一段时间持续增加的服务端延迟，则应向 亚马逊云科技 Support 提交支持案例，他们将与 DynamoDB 服务团队联系以确认并解决问题。

什么是客户端延迟？

如果 Su ccessfulRequest Latency 指标未显示高延迟，但您的应用程序的延迟仍高于正常水平，则客户端延迟很可能高于正常水平。

应用程序和 DynamoDB 端点之间的流程如下面的图 1 所示。流程从用户通过互联网到 DynamoDB 终端节点。然后处理请求，并将响应从 DynamoDB 端点通过互联网返回给用户。

Figure 1: Architecture diagram showing the flow between the application and the DynamoDB endpoint

图 1：显示应用程序和 DynamoDB 端点之间流程的架构图

通常，出现高于正常客户端延迟的原因是：

  • 从客户端到 DynamoDB 公共端点的网络延迟。
  • 从 DynamoDB 公共端点到客户端的网络延迟。
  • 客户端应用程序需要比平时更多的时间来处理从 DynamoDB 公共端点获得的结果。

要确定此问题是否来自客户端，建议您启用 SDK 指标 。这些指标可以帮助您确定延迟增加的来源。有关 使用 亚马逊云科技 开发工具包记录 延迟指标的更多信息， 请参阅 如何解决 Amazon D ynamoDB 表上的高延迟 问题。

您可以使用 亚马逊云科技 SDK 指标来了解 API 在哪里花费的时间最多。默认情况下，此功能处于禁用状态。例如，使用适用于 Java 的 亚马逊云科技 开发工具包 ，您可以在启动 Java 应用程序时添加指向您的 亚马逊云科技 安全证书文件的系统属性来启用指标。以下命令启用 Java SDK 的默认指标： 

-Dcom.amazonaws.sdk.enableDefaultMetrics=credentialFile=/path/aws.properties

注意： 请务必 更改 /path/aws.properties 以匹配您的配置 。

要启用 boto3 的 SDK 指标 ，请将以下内容添加到您的环境变量中。 

export AWS_CSM_ENABLED=true

有关其他可用的配置设置，请参阅 SDK 指标 。

下面的图 2 显示了使用 Putit emRequest 写入 DynamoDB 时客户端 HTTP 响应时间（httpClientReceiveResponseTime ）与客户端总请求完成时间 （clientExecuteTime）的对比。 这张图只是一个示例，与你的延迟可能并不完全匹配。

Figure 2: Graph showing SDK client-side metrics

图 2：显示 SDK 客户端指标的图表

现在您已经了解了服务端和客户端延迟以及如何处理这两者，让我们回顾一下其他一些有助于减少延迟的重要的 DynamoDB 功能。

DynamoDB 客户端灵活性

每当一项服务或系统调用另一项服务或系统时，都可能发生故障。这些故障可能来自多种来源，包括服务器、网络、负载平衡器、软件和操作系统。亚马逊云科技 系统旨在降低故障的可能性，并在出现故障时保持弹性，我建议我们的客户对他们的系统也这样做。您可以使用三种策略来帮助构建弹性系统，包括超时、重试和退避。

超时和重试

为了减少系统故障情况下的延迟，最好快速失败并从应用程序代码中启动下一次重试，以避免使用默认的指数退避算法。要快速失败，您需要为 DynamoDB API 调用设置较短的请求超时时间，这样 亚马逊云科技 开发工具包就会在请求超时时自动重试，而不是无限期地等待 DynamoDB 返回结果。由于 DynamoDB 的分布式特性，如果您发送新的应用程序重试，则请求可能会在第二次尝试时转到运行状况良好的节点，因此可以更快地返回结果。有关 如何实现这一目标的指南，请参阅调整适用于 Java 的 亚马逊云科技 开发工具包以提高灵活性。 使用 usetcpKeepAlive 设置还将导致每个连接产生更多请求，这将帮助您降低 DynamoDB 客户端的延迟。

重试和退缩

如果您未指定重试算法，亚马逊云科技 SDK 将使用指数退避算法。您有责任修改 SDK 配置，以避免更长的重试时间，这会给应用程序逻辑带来延迟。指数退避背后的想法是，在两次重试之间使用逐渐更长的等待时间来获得连续的错误响应。您应该实现最大延迟间隔和最大重试次数。最大延迟间隔和最大重试次数不一定是固定值，应根据正在执行的操作以及网络延迟等其他本地因素进行设置。大多数指数退避算法的 亚马逊云科技 SDK 实现都使用抖动（随机延迟）来防止连续发生冲突。如果你使用并发客户端，抖动可以帮助你的请求更快地成功。有关更多信息，请参阅 指数退避和 抖动。

使用 DynamoDB 全局表

我推荐你使用 DynamoDB 全局 表的主要原因有两个。

  1. 提供快速、本地化的读写性能并改善用户的应用程序体验。
  2. 业务连续性和灾难恢复

使用低延迟应用程序改善用户体验

任何现代应用程序的成功都与网络延迟和网络吞吐量直接相关。为了减少网络延迟和提高网络吞吐量，全球的内容提供商使用诸如 Amazon CloudFron t之类的内容分发网络 ，这使静态内容更接近用户。这减少了延迟并改善了用户体验。

但是，尽管CloudFront解决了交付静态内容的问题，但仍需要在后端进行一些动态调用，而且后端服务器可能很远，从而为请求增加了宝贵的时间。对于许多流行的游戏、电子商务平台和其他交互式应用程序来说，这些延迟是不可接受的。您可以使用 DynamoDB 全局表 将数据带 给分散在全球各地的用户。数据的复制由 DynamoDB 内部处理。您的应用程序可以随时连接到最近的全局表副本来为请求提供服务。

下面的图 3 代表了 DynamoDB 全局表 架构以及全球应用程序和分散在世界各地的用户。

Figure 3: DynamoDB global table architecture

图 3：DynamoDB 全局表架构

业务连续性和灾难恢复

在设计任务关键型工作负载时，应考虑资源故障的可能性。资源故障是不可避免的，当它们发生时，它们会增加应用程序的整体延迟，从而降低客户体验。因此，您需要设计应用程序，使其能够承受资源故障并快速自动地从故障中恢复。

通过使用全局表，如果单个 亚马逊云科技 区域变得隔离或降级，或者如果应用程序面临的延迟高于正常水平，则您的应用程序可以重定向到另一个区域并对不同的副本表执行读取和写入。您可以应用自定义业务逻辑来确定何时将请求重定向到其他区域。要了解更多信息，请参阅博客系列 使用 Amazon DynamoDB 全局表 构建弹性应用程序 。

当区域被隔离或降级时，DynamoDB 会跟踪所有已执行但尚未传播到所有副本表的写入操作。当该区域恢复联机时，DynamoDB 会继续将来自该区域的所有待处理写入内容传播到其他区域的副本表。它还会继续将写入内容从其他副本表传播到现在已恢复在线的区域。要了解更多信息，请参阅 全局表格：其工作原理 。

注意： 全局表的 跨区域复制由 DynamoDB 管理，但您的应用程序将要连接的 DynamoDB 终端节点由您负责。

DynamoDB 加速器 (DAX)

如果您的应用程序读取量大，建议 使用亚马逊 DynamoDB 加速器 (DAX ) 来缓存热门项目。 DAX 是 D ynamoDB 的完全托管、高度可用的内存缓存，即使每秒有数百万个请求，也能以低至亚毫秒的延迟交付请求。使用 DAX，无论读取分布如何，第一个请求都会发送到 DynamoDB 表，但随后的所有最终一致性读取请求都从内存中完成。这意味着使用 DAX 将改善您的延迟性能，并有可能降低您的 DynamoDB 成本，因为 DAX 会减少发送到您的 DynamoDB 表的读取请求数量。

结论

在这篇文章中，我描述了您在使用 DynamoDB 时可能会遇到的两种不同的延迟类型——服务端延迟和客户端延迟。有关减少延迟的方法的建议包括：

  • 启用 亚马逊云科技 SDK 指标 以解决客户端延迟问题。
  • 减少连接超时。
  • 使用全局表来减少延迟并促进灾难恢复。
  • 使用 DAX 缓存热门项目。

如果您在采用本博客文章中描述的做法后继续遇到高延迟，请联系 亚马逊云科技 支持 以获得进一步的故障排除和帮助。

如果您对此帖子有疑问或反馈，请发表评论。

作者简介

Sandip Gangdhar 是亚马逊网络服务的云架构师，也是 DynamoDb 的主题专家。他在使用云技术方面拥有十多年的经验。在亚马逊云科技，他主要专注于通过战略技术采用可以实现的变革性业务成果，将客户提升到一个新的水平。工作之余，他喜欢与家人共度时光。

*前述特定亚马逊云科技生成式人工智能相关的服务仅在亚马逊云科技海外区域可用，亚马逊云科技中国仅为帮助您发展海外业务和/或了解行业前沿技术选择推荐该服务。