相信大家已经都知道，Amazon DynamoDB 是一项全托管的 NoSQL 数据库服务，适合所有需要一致性且延迟低于 10 毫秒的任意规模的应用程序，支持文档和键值存储模型。使用 DynamoDB，可创建数据库表来存储和检索任意量级的数据，并提供任意级别的请求流量。现在，DynamoDB 还提供了 Auto-Scaling 的功能，即可以通过你预先设置的阈值自动扩展和缩减表的吞吐量，做到完全弹性自动伸缩的目的，真正达到让你的数据库按实际吞吐量进行付费。
这么高的并发量却依然可以保持服务器的平均延迟在个位数毫秒，这让 DynamoDB 受到了非常多用户的青睐。然而随着大数据时代的数据暴增，很多客户的场景比较特殊，他们对数据库的响应时间越来越苛刻，甚至需要达到微秒的级别！这无疑给 DynamoDB 数据库又带来了一个难题。甚至也有客户会提到，能不能在 DynamoDB 前面放一层类似 Redis 的 Cache 服务呢？如果这样做的话，需要自己搭建缓存数据库，并且解决 DynamoDB 和 Redis 之间的数据同步问题；同时还要重写代码实现业务逻辑，比如如果数据在缓存中，则立即返回，如果数据没有在缓存中，则必须从数据库里面读取，将数据写入到缓存中，然后再返回。
当用户还带着这样的担心时，现在，Amazon DynamoDB 已经整合了这一特性，推出了一个新的功能，即 Amazon DynamoDB Accelerator，简称 DAX。这是一种完全托管并且高度可靠的内存缓存，即使每秒种的请求量达到数百万，却依然可以将 Amazon DynamoDB 的响应时间从数毫秒缩短到数微秒！其实在很多场景都可以用到 DAX，比如实时竞拍、秒杀、电商、社交游戏等场景，DAX 可以提供快速的内存读取性能；再比如在产品促销日，读取访问量会明显上升，但是销售日结束访问量就会回归正常，诸如此类读取密集型的工作负载但同时又对成本敏感的应用都可以使用 DAX 服务。像类似于 Expedia、Twilio、Genesys、eyeview 等客户都已经率先用上了 DAX 服务
目前，DAX 还是处于预览版，您可以点击链接进行申请。接下来，让我们创建一个 DAX 集群，赶紧体验一下微秒级别的响应测试吧！
1. DAX 集群的原理
上图中可以看到，DAX 起了一组缓存的节点（目前最多可以是 10 个节点），并将这些节点置放在 VPC 内部，应用程序部署在 EC2 上，这样 EC2 和 DAX Cluster 通过内网直接访问。关于 DAX 的内存缓存，主要是 DynamoDB 的读和写操作：
（1）最终一致性的读取操作，支持 GetItem、BatchGetItem、Query、Scan 接口，如果读取在 DAX 缓存中命中，将直接从 DAX 集群里读取；如果是第一次读取没有命中，那就从 DyanmoDB 里面读取。
（2）写入操作支持 BatchWriteItem、UpdateItem、DeleteItem、PutItem 接口，写入的时候数据先写入到 DynamoDB 表，确认写入成功之后，然后再写到 DAX 集群（item cache），这个操作只有在 DynamoDB 表和 DAX 集群都写入了数据的时候才算成功。如果由于一些原因这个操作失败了，那么这个 item 将不会缓存到 DAX 里面，并且会抛出一个 exception。这种方式可以让缓存和数据库的数据保持一致性和完整性，不会出现过期数据在缓存里面。
（3）如果 DAX 有多个节点时，会选取一个主节点（primary node），多个从节点（read replica node），数据最终会分布到所有节点上，但对于客户端来说，只需要关心唯一的 DAX 连接地址，已经内置了负载均衡和路由策略，并且自动执行故障检测、故障恢复、软件修补等管理任务。
接下去，我们将模拟这一过程，进行实际测试。
2. 启动 DAX 集群
首先启动一个 DAX 集群，指定集群的节点数（目前节点最多为 10 个），我们建议您在生产环节中启用两个以上的节点，并将这些节点置放在不同的可用区中，从而提高高可用。设置好相应的 IAM Role 和 Policy。Policy 可以配置“只读”权限，或者“读和写”权限。更多关于权限配置可以参考:
http://s3.amazonaws.com/dynamodb-preview-dax/DAX.access-control.html
接下去设置 DAX 集群的子网组，DAX 集群的节点会部署在这些子网里面。选定 VPC 和相对应的子网，并设置安全组。安全组入站需要打开 DAX 所用到的 8111 端口。
接下去配置 DAX 的参数组，指定 Cache 的 Query TTL 和 Item TTL 值。TTL 的时间小到可以是“秒”，大到可以到“天”。
也可以自定义选定维护窗口，如果需要的话可以再加一个 SNS 通知，这样只要集群有维护就会立刻以短信，或者邮件等形式通知到您。
到这里，DAX 集群就创建成功了。DAX 集群会有一个唯一的 endpoint 地址，例如，这里是
dax-cluster-demo.bnsilv.clustercfg.dax.usw2.cache.amazonaws.com:8111
另外可以看到在这个例子中 DAX 集群启动了 3 个节点。
DAX 集群具体的 3 个节点
3. 启动 EC2 ，作为应用程序的 server，同时作为 DAX 的 client
如果仅作为测试，可以启动一台 t2.micro 的小型机器（Amazon Linux）。
EC2 通过监控检查，启动成功。
4. 安装 Java 应用程序
（1）首先通过客户端连接到这台 Amazon Linux EC2
（2）安装 Java SDK
sudo yum install -y java-devel
（3）下载最新版的 AWS Java SDK
wget https://s3-us-west-2.amazonaws.com/danrongdemo/DynamoDB-Accelerator-Test-Demo/aws-java-sdk-1.11.125.zip
unzip aws-java-sdk.zip
（4）下载最新版的 DAX Jave 客户端
wget https://s3-us-west-2.amazonaws.com/danrongdemo/DynamoDB-Accelerator-Test-Demo/DaxJavaClient-latest.jar
（5）设置 CLASSPATH 环境变量
export SDKVERSION=1.11.125
export CLASSPATH=.:./DaxJavaClient-latest.jar:aws-
java-sdk-$SDKVERSION/lib/aws-java-sdk-$SDKVERSION.jar:aws-
java-sdk-$SDKVERSION/third-party/lib/*
（6）下载 Java 应用程序代码
wget https://s3-us-west-2.amazonaws.com/danrongdemo/DynamoDB-Accelerator-Test-Demo/TryDax.zip
unzip TryDax.zip
（7）编译代码：javac TryDax*.java
（8）执行代码：java TryDax
以下是完整的应用程序拓扑图
5. 直接读取 DynamoDB 表的响应测试
从图中可以看到，直接从 DynamoDB 表里进行读取数据，分布执行了 GetItem、Query、Scan 操作，服务器的平均延时在个位数毫秒级别（小于 10ms）。
此时查看 DAX 的监控还没有任何 cache 指标产生：
6. 加上 DAX 后进行测试
调整 DAX 的 endpoint，通过代码判断当 daxClient 不为空时，就会采用 DAX 方式去查询。
将 DAX 的 endpoint 以参数形式传入执行，代码会判断 DynamoDB 的读取操作启用 DAX 内存缓存。
再次执行查询操作，发现:
上图中可以发现，第一次通过 GetItem 读取的时候由于 DAX 集群中没有数据，所以直接读取 DynamoDB 表，延迟在 4.7ms 左右，与此同时，会把数据写入到 DAX 集群中。当再次进行 GetItem 读取的时候，会直接从 DAX 内存缓存中读取，响应时间大概在 0.8ms 左右。同理，对于 Query 操作也可以发现，第一次查询 DynamoDB 表的响应时间是 17.2ms，但是第二次读取时直接从 DAX 进行查询，响应时间缩短到了 0.5ms 左右。因此，不管是 GetItem，Query 还是 Scan 操作，读取操作的响应时间都已经大大提升了！另外，对于读取和写入操作，DAX 已经自动集成了 CloudWatch 进行监控，很容易可以监控例如 CPU 使用率，Item Cache 命中数，Query Cache 命中数，总共的请求数等 19 个指标。
7. 如何将 DAX 整合到现有的 DyanmoDB 开发中？
您有可能会关心，我现在的业务代码已经基于 DynamoDB 开发好了，如何要把 DAX 整合进去，代码的开动量会不会很大呢？这一问题 AWS 已经替您考虑到了，例如有一张名为 Music 的表，主键（partition key）是 Artist，排序建（sort key）是 SongTitle。直接上代码:
8. 如何增加 DAX 的集群节点数？
增加 DAX 的节点数，可以通过 API 或者命令行操作，点击“Add node”：
然后选择新增加节点的个数，可以自定义 DAX 节点所在的可用区。如下：
9. 小结
如果您已经在使用 Amazon DynamoDB 了，集成 DAX 只需要稍微改动一下 DAX client 的实现，核心的业务逻辑代码基本上不用做任何改动。
DynamoDB 的服务器平均延时在个位数毫秒级别，但是新出的 DAX 功能和 DyanmoDB 配合起来使用，则可以性能进一步推到一个新的层级，在处理每秒接收数以百万计请求的读取密集型工作负载时，响应时间缩短到以微秒级别，大概在 0. 几个 ms 左右。效果还是蛮惊人的！
更多 DAX 的介绍: https://aws.amazon.com/cn/dynamodb/dax/
关于 DAX 的价格: https://aws.amazon.com/cn/dynamodb/pricing/
作者介绍
毛郸榕
AWS 解决方案架构师，负责基于 AWS 的云计算方案架构的咨询和设计，同时致力于 AWS 云服务在国内的应用和推广，毕业于北京航空航天大学云计算专业，硕士，毕业后直接加入亚马逊 AWS 中国。在大规模后台架构、企业混合 IT 和自动化运维等方面有着丰富的实践经验。目前在集中精力学习新一代无服务器架构的开发与设计。
本文转载自 AWS 技术博客。
原文链接：
https://amazonaws-china.com/cn/blogs/china/dax-dynamodb-fully-managed-in-memory-cache/
评论