无需改写应用，将 DynamoDB 的响应时间从毫秒提升到微秒

传统的缓存场景通常是进行旁路的部署，需要考虑使用新的 API 接口、大量的应用修改，以及需要管理缓存的伸缩性和高可用等方面。用户的应用开发和运维管理工作的压力很大，因此一直期望有一个高性能、高可用并且简单易用的方案来做数据库的缓存。

什么是 DynamoDB Accelerator（DAX）？

Amazon DynamoDB Accelerator (DAX) 是适用于 DynamoDB 的完全托管且高度可用的内存中缓存，可实现高达 10 倍的性能提升（从毫秒缩短到微秒），即使在每秒处理的请求数量达到数百万个的情况下也是如此。DAX 将为您完成为 DynamoDB 表格进行内存加速的所有繁重任务，使开发人员无需再管理缓存失效、数据填充或集群管理等活动。

现在，您可以集中精力为您的客户构建出色的应用程序，而无需担心规模性能。您不需要修改应用程序逻辑，因为 DAX 可与现有的 DynamoDB API 调用兼容。

DAX 部署架构和优势

DAX 部署架构如下图：

DAX 的主要优势有：

• 极致性能

虽然 DynamoDB 可以提供一致的个位毫秒延迟，DynamoDB + DAX 则将性能进一步推上新水平，在处理每秒接收数以百万计请求的读取密集型工作负载时，响应时间以微秒为单位计。借助 DAX，您的应用程序将反应敏捷、快速，即使在热门事件或新闻故事产生前所未有的请求量时也不例外。无需优化。

• 高度可扩展

有了 DynamoDB + DAX，您再不必对性能和规模作出妥协。DAX 让您能按需扩展。您可以最先建立一个三节点 DAX 集群，以后通过添加更多节点来增加容量。DAX 可最多扩展到十节点集群，每秒接收数百万计请求。

• 完全托管

和 DynamoDB 一样，DAX 是完全托管的。您无需再担心管理任务，例如，硬件或软件预置、设置和配置、软件修补、运行可靠的分布式缓存集群，或者在扩展过程中将数据复制到多个实例。DAX 将自动执行许多一般性管理任务，例如，故障检测、故障恢复和软件修补。

• 易于使用

DAX 与 Amazon DynamoDB 紧密集成 – 您只需预置一个 DAX 集群，使用 DAX Client SDK 指向 DAX 集群中您现有的 DynamoDB API 调用，DAX 会为您处理余下的工作。由于 DAX 与 DynamoDB API 兼容，所以无需作出任何功能性应用程序代码更改。DAX 在后台执行所有繁重任务，以提高性能。此外，由于检索缓存数据会减少现有 DynamoDB 表格上的读取负载，您还可以通过减少它们的预置读取容量降低总运行成本。

• 灵活

借助 DAX，您可以为多个 DynamoDB 表格预置一个 DAX 集群，为一个 DynamoDB 表格预置多个 DAX 集群，或者两者兼有，以获得最大的灵活性。

• 安全

DAX 与 AWS 完全集成，以加强安全性。您可以使用 Identity and Access Management (IAM) 为每个用户分配唯一安全凭证，并管理每个用户对不同服务和资源的访问权限。您可以通过使用 Amazon CloudWatch 全面地了解整个系统的资源使用率、应用程序性能和运行状况。与 AWS CloudTrail 集成，使您可以轻松记录和审查您的集群配置的变化。DAX 可支持 Amazon Virtual Private Cloud (VPC)，为您的现有应用程序实现安全又方便的访问。标记功能则为您提供了更大的可见性，有助于您管理 DAX 集群。

DAX 的使用场景

DAX 提供了针对 DynamoDB 表中最终一致性数据的访问权限（延迟以微秒为单位）。一个多可用区 DAX 集群每秒可处理数百万个请求。

DAX 非常适合以下类型的应用程序：

• 需要尽可能短的读取响应时间的应用程序。某些示例包含实时出价、社交游戏和交易应用程序。DAX 为这些使用案例提供了快速的内存内读取性能。

• 比其他应用程序更频繁地读取少量项目的应用程序。例如，考虑一个电子商务系统，该系统对某个热门产品进行了一日促销。在销售期间，与所有其他产品相比，对该产品 (及其在 DynamoDB 中的数据) 的需求将急剧增加。为了消除某个“热”键和不均匀流量分配的影响，您可以将读取活动分载到一个 DAX 缓存，直到一日促销结束。

• 不但需要进行大量读取，而且对成本很敏感的应用程序。利用 DynamoDB，您可以预置您的应用程序需要的每秒读取次数。如果读取活动增加，您可以增加您的表的预置读取吞吐量 (需额外付费)。或者，您也可以将活动从您的应用程序分载到某个 DAX 集群，并减少您需要另行购买的读取容量单元的数量。

• 需要针对一组大型数据进行重复读取的应用程序。此类应用程序可能会从其他应用程序转移数据库资源。例如，一个长时间运行的区域气候数据分析可能会临时消耗掉 DynamoDB 表中的所有读取容量。这种情况对需要访问相同数据的其他应用程序会产生负面影响。利用 DAX，可以改为针对缓存数据进行天气分析。

DAX 不适合 以下类型的应用程序：

• 需要强一致性读取 (或无法容忍最终一致性读取) 的应用程序。

• 不需要读取的微秒响应时间的应用程序，或不需要分载基础表中的重复读取活动的应用程序。

• 需要进行大量写入或不执行太多读取活动的应用程序。

• 已在将其他缓存解决方案用于 DynamoDB 并将其自己的客户端逻辑用于使用该缓存解决方案的应用程序。

应用测试示例—使用 DAX 做缓存减少响应时间到微秒

为了让大家能够直观的感受 DAX 所带来的性能提升，下面做一个快速的测试示例：创建一个 DAX 集群，分别测试应用程序对 DynamoDB 直接访问和通过 DAX 的缓存访问。

首先，进入 AWS 管理控制台，选择“宁夏区域”，

然后选中 DynamoDB 服务，单击 DAX 的控制面板。

• 创建集群

选中“创建集群”，进入配置界面。输入集群名称 dax1，选择节点类型和集群初始大小，并且创建 IAM 角色和 policy 用于允许 DAX 访问 DynamoDB 的表。

在目标 DynamoDB 表这里，可以选择“所有表”，也可以根据需要选择相应的一张表。接下来，创建一个子网组用于放置所有的 DAX 节点，命名这个子网组并且选择需要的子网。

选中“使用默认设置”，并点击“启动集群”。

可以看到，在几分钟后，DAX 集群已经开始正常运行了（注意：需要对 DAX 集群所附加的安全组，添加 8111 端口的允许访问策略）。

• 应用测试

接下来，可以使用 AWS 官方网站 DynamoDB 文档中的示例应用来进行测试操作。本次测试选择使用 Java 示例应用程序，您也可以选择熟悉的 Python、.Net 或 Node.js 示例来测试。

为了查看 DAX 如何工作，接下来安装 Java 应用程序 TryDax，并且执行两次。第一次执行，用 Java 程序直接对 DynamoDB 进行查询、scan 等操作，查看各个操作的运行时间。

可以看到基本操作的响应时间都在几个毫秒，这是没有 cache 的基本性能指标。

第二次使用 DAX，查看 cache 数据后的性能。

进入 DAX 的集群管理界面，记录下 dax1 集群的终端节点，

在这里是（dax1.xmemqv.clustercfg.dax.cnw1.cache.amazonaws.com.cn:8111），将其配置为 Java 应用程序的第二次运行目标。

运行的结果如下：

其中 GetItem、Query 和 Scan 操作第一行的响应较慢是由于 cache miss，后面的几次响应时间都在零点几个毫秒，是从 DAX 取得的缓存结果，明显比直接从 DynamoDB 要快很多。

• 小结

所以，从应用配置和使用的角度来看，采用 DAX 做数据库缓存方案非常简单方便，无需应用做修改，只要在应用执行时加上 DAX 的终端节点，就可以立刻获得极大的性能提升。

下面为两次应用执行的图示，可以看到第一次执行的是：

$java TryDax

而第二次执行的时候，采用 DAX 做数据库缓存，应用执行时加上了终端节点：

$java TryDax dax1.xmemqv.clustercfg.dax.cnw1.cache.amazonaws.com.cn:8111

作者介绍：李迎峰，AWS 解决方案架构师，目前负责企业应用架构设计工作，有丰富的数据库系统和企业应用系统经验。

本文转载自 AWS 技术博客。

原文链接：https://amazonaws-china.com/cn/blogs/china/dynamodb-accelerator-increases-the-response-time-of-dynamodb-from-milliseconds-to-microseconds-without-rewriting/