Amazon DynamoDB Accelerator
在 DynamoDB 前端部署内存缓存，将读取延迟从毫秒级降低到微秒级的全托管缓存服务
概述
Amazon DynamoDB Accelerator (DAX) 是专为 DynamoDB 设计的内存缓存集群。由于与 DynamoDB API 完全兼容，只需将应用程序的端点更改为 DAX 集群，即可将读取延迟从毫秒级降低到微秒级。写入操作通过直写方式透明地反映到 DynamoDB，缓存一致性自动维护。
与 ElastiCache 的选型标准及 DAX 特有限制
DAX 和 ElastiCache for Redis 都是内存缓存，但用途明显不同。DAX 专用于 DynamoDB，可以直接使用 DynamoDB API，因此应用程序的改动最小。它通过项目缓存和查询缓存两层自动缓存 GetItem、BatchGetItem、Query、Scan 的结果，当相同请求到来时无需访问 DynamoDB 即可返回结果。ElastiCache 是通用缓存，可以缓存 DynamoDB 以外的数据源（RDS、外部 API 结果、会话数据等）。还可以利用 Redis 的数据结构（Sorted Set、Hash、List）实现复杂的缓存逻辑。应该选择 DAX 的场景是：DynamoDB 读取负载高，且相同的键或查询模式被反复执行的工作负载。DAX 的限制包括：只能从 VPC 内访问（从 Lambda 使用时需要 VPC 连接）、强一致性读取会绕过缓存直接访问 DynamoDB、每个表需要单独的集群。对于写入多读取少的工作负载，DAX 的成本效益不高。
集群设计与缓存策略
生产环境推荐 DAX 集群至少配置 3 个节点（多可用区）。节点类型为 dax.r5 系列，根据缓存数据量选择内存大小。项目缓存的 TTL（默认 5 分钟）和查询缓存的 TTL（默认 5 分钟）可以独立设置，根据数据更新频率进行调整。更新频率低的主数据可以设置较长的 TTL（1 小时以上），频繁更新的数据则设置较短的 TTL（几十秒）。缓存命中率可通过 CloudWatch 的 ItemCacheHits / (ItemCacheHits + ItemCacheMisses) 计算，目标是 80% 以上。如果命中率低，可能是访问模式不适合缓存（每次访问不同的键）。DAX 的成本按节点小时计费，dax.r5.large（3 节点）的月费约为 600 美元。在引入前需要将 DynamoDB 读取容量单位（RCU）的节省额与 DAX 成本进行对比评估。
游戏排行榜与实时应用中的应用
DAX 最能发挥效果的是读取集中在少数热键上的工作负载。在游戏排行榜中，所有玩家都会反复执行排名靠前的查询。没有 DAX 时，DynamoDB 的分区会产生热点，存在限流风险，而 DAX 缓存查询结果后可以大幅减少对 DynamoDB 的负载。电商网站的商品目录也类似，热门商品详情页会产生大量相同的 GetItem 请求，DAX 的项目缓存非常有效。在实时竞价系统中，当前最高出价被频繁读取，而更新仅在出价时发生。将 DAX 的 TTL 设置为几秒，即可在返回近乎实时数据的同时将 DynamoDB 的读取负载降低 90% 以上。另一方面，对于每次使用不同条件执行 Scan 的分析查询，查询缓存命中率会很低，DAX 的效果有限。这种情况下，将 DynamoDB 数据导出到 S3 并使用 Athena 进行分析更为合适。