通过 Amazon DynamoDB Accelerator (DAX) 实现微秒级延迟 - 内存缓存设计
解说通过 DAX 加速 DynamoDB 读取、缓存策略和集群设计。
DAX 概述
DAX 是 DynamoDB 的内存缓存，将读取延迟从毫秒缩短到微秒。与 ElastiCache（Redis/Memcached）不同，它提供 DynamoDB 兼容的 API，但连接需要使用 DAX 客户端，单靠更换端点无法完成切换。DAX 集群部署在 VPC 内，集群中的每个节点保存相同缓存数据的副本。主节点处理写入，副本节点分散读取负载，主节点故障时副本自动提升为主节点。
缓存策略与集群设计
项目缓存缓存 GetItem 和 BatchGetItem 的结果，通过 TTL（默认 5 分钟）自动失效。查询缓存缓存 Query 和 Scan 的结果集。通过写透（Write-Through），执行 PutItem 或 UpdateItem 时项目缓存也会更新（查询缓存不会随之更新）。集群推荐最少 3 节点（多可用区），节点类型根据缓存数据量选择。dax.r5.large 适合中等规模工作负载，dax.r5.xlarge 适合拥有大量热数据集的场景。
缓存策略与一致性
DAX 通过项目缓存和查询缓存两层管理缓存。项目缓存以 TTL（默认 5 分钟）保持 GetItem 和 BatchGetItem 的结果。查询缓存保持 Query 和 Scan 的结果。写入操作（PutItem、UpdateItem、DeleteItem）通过写透同时反映到 DAX 和 DynamoDB。最终一致性读取从缓存返回，强一致性读取直接访问 DynamoDB。TTL 设置过短会降低缓存命中率，设置过长会降低数据新鲜度，存在权衡。
DAX 与 ElastiCache 的比较
DAX 是 DynamoDB 专用缓存，通过将应用程序的 SDK 替换为 DAX 客户端来引入。项目缓存的失效由 DAX 处理，因此应用程序端无需实现失效逻辑。而 ElastiCache (Redis) 可以缓存 DynamoDB 以外的数据源（RDS、外部 API 响应），并能利用 Pub/Sub 和有序集合等数据结构。DAX 的查询缓存通过参数完全匹配判定命中，因此 Query 过滤条件频繁变化的工作负载命中率会下降。此时也可以使用 ElastiCache 在应用端设计缓存键。TransactGetItems 请求会直接传递给 DynamoDB 且结果不会被缓存，因此对于以事务读取为主的工作负载效果有限。
设计陷阱与运维注意事项
DAX 集群必须部署在 VPC 内。从 Lambda 连接时，需将 Lambda 放在同一 VPC 中。DAX 节点故障时，客户端 SDK 自动重试，但故障转移期间读取延迟会增加。应用程序应设计为容许这种暂时性延迟增加。项目缓存和查询缓存的 TTL 可独立设置。对写入频繁的表，应缩短项目缓存 TTL，并一并检查查询缓存 TTL 以维持数据新鲜度。节点的添加和删除可在集群运行时执行，新添加的节点会从其他节点同步缓存数据，因此应在预期的流量高峰之前完成。
DAX 的费用
DAX 按节点小时计费，费率因节点类型而异。推荐 3 节点以上（多可用区）的配置，因此需支付相应节点数的费用。比较 DynamoDB 读取容量单位（RCU）的成本削减效果与 DAX 节点成本，判断在读取密集型工作负载中引入 DAX 是否有利。缓存命中率越高，越能减少 DynamoDB 的 RCU。
总结
DAX 是 DynamoDB 的内存缓存，实现微秒级读取延迟的服务。通过写透缓存维持写入一致性，同时通过项目缓存和查询缓存两层减轻读取负载。在缓存命中率高的读取密集型工作负载中，DynamoDB 的 RCU 成本削减效果容易显现。
参考资料（AWS 官方）
本页的第一手信息来源是 AWS 官方网站及官方文档。最新的规格与价格请以下列官方页面为准。
如本页内容与官方文档不一致，请以官方文档为准。