为商品查询添加缓存

简介

商品应用每次请求都从 DynamoDB 读取目录。添加运行 Valkey 的 Amazon ElastiCache 节点，让重复请求复用商品值。通过响应来源和实际来源读取次数证明变化。

先完成 AWS Foundations for Beginners，并掌握 AWS DynamoDB for Beginners 中的基本条目操作。本独立环境提供商品应用、目录和网络配置。使用 Terminal 执行命令，通过 AWS View 观察当前节点、源记录及应用响应。AWS CLI 已配置，无需个人 AWS 账户或另一实验的资源。

认证考点

观察商品来源

本步骤观察尚未使用缓存的商品应用。缓存将可复用的数据保存在内存中。数据库仍是权威来源：缓存值丢失不能导致目录记录丢失。先观察提供的应用在接入缓存之前的行为。

在提供的项目目录中操作，并确认已配置的身份：

cd /home/labex/project
aws sts \
  get-caller-identity

ARN 以 labex-ca01-operator 结尾，标识你将查询资源的当前环境。

直接从 DynamoDB 表读取商品 101。DynamoDB 用 S 表示字符串，用 N 表示数字：

aws dynamodb \
  get-item \
  --table-name product-catalog \
  --key '{"product_id":{"S":"101"}}' \
  --consistent-read

记录描述价格为 20.00 的 Travel mug。另一商品 202 是独立的 Notebook 记录，本实验中应保持不变。

提供的 HTTP 应用返回商品 JSON。请求同一个商品两次：

curl -sS http://127.0.0.1:8080/api/products/101
curl -sS http://127.0.0.1:8080/api/products/101

两个响应都包含 "served_from":"source"。打开 AWS View：来源读取次数增加了两次，ElastiCache 卡片还没有集群。来源读取表示应用实际向 DynamoDB 请求了条目，不代表测量了 AWS 账单费用。

Send request 控件会发送另一条真实应用请求，也可能改变来源读取次数。因此你的计数可能与示例不同。关注计数是否变化，而非固定的最终数字。

创建 Valkey 缓存节点

本步骤创建并连接缓存节点。Amazon ElastiCache管理内存缓存引擎。Valkey按键存储值；这里用商品 ID 标识缓存商品。本练习使用一个独立节点。提供的子网组标识已准备的网络位置，安全组是其网络配置。网络规则设计由 VPC 课程教授。

读取当前新环境提供的网络标识符：

cat resources.json

保存并显示安全组 ID。$(...) 保存命令输出，以供下一操作使用：

CACHE_GROUP_ID=$(jq -r .security_group_id resources.json)
echo "$CACHE_GROUP_ID"

创建小型单节点缓存。集群标识符 product-cache 为资源命名；引擎和节点数选择本课程的 Valkey 配置：

aws elasticache \
  create-cache-cluster \
  --cache-cluster-id product-cache \
  --engine valkey \
  --engine-version 7.2 \
  --cache-node-type cache.t3.micro \
  --num-cache-nodes 1 \
  --cache-subnet-group-name product-cache-network \
  --security-group-ids "$CACHE_GROUP_ID"

观察 CacheClusterStatus。查询节点详情，获得应用连接的端点，即地址和端口：

aws elasticache \
  describe-cache-clusters \
  --cache-cluster-id product-cache \
  --show-cache-node-info \
  --query 'CacheClusters[0].{Status:CacheClusterStatus,Nodes:CacheNodes}'

当集群为 available 且节点 0001 有端点时继续。若仍在创建，稍等片刻后重复查询。

保存并显示实际端点地址：

CACHE_HOST=$(aws elasticache \
  describe-cache-clusters \
  --cache-cluster-id product-cache \
  --show-cache-node-info \
  --query 'CacheClusters[0].CacheNodes[0].Endpoint.Address' \
  --output text)
echo "$CACHE_HOST"

使用提供的 Valkey 客户端测试真实连接：

valkey-cli -h "$CACHE_HOST" -p 6379 PING

PONG 证明缓存引擎已响应，但还不能证明商品应用正在使用它。AWS View 现在列出实际缓存节点和端点。

连接应用并观察缓存命中

本步骤配置应用并比较响应来源。应用支持 cache-aside：首先在缓存中查找 product:101。键不存在称为未命中；应用读取 DynamoDB 并保存商品。后续命中直接返回该缓存值，无需再次回源。

提供的 app.json 保存普通应用设置。使用 jq 修改模式和端点，先写临时文件，再一并替换配置：

jq --arg host "$CACHE_HOST" \
  '.mode = "cache-aside" | .cache_host = $host' \
  app.json > app.next.json
mv app.next.json app.json

查看新配置：

cat app.json

应用每次请求都会读取该配置，无需重启。ttl_seconds 是缓存值的存活时间；下一实验将探索到期和数据新鲜度。

请求商品 101 一次：

curl -sS http://127.0.0.1:8080/api/products/101

首次请求返回 served_from: source：新缓存中尚无商品值。在 AWS View 观察来源读取次数，然后重复请求：

curl -sS http://127.0.0.1:8080/api/products/101

响应返回 served_from: cache，商品 ID、名称和价格相同，来源读取次数保持不变。如果此前通过 AWS View 发送过请求，第一次 Terminal 请求可能已命中；在缓存填充后比较两个连续请求。

使用 Valkey 客户端读取实际缓存值：

valkey-cli -h "$CACHE_HOST" -p 6379 GET product:101

JSON 对应 Travel mug 的源记录。你证明了重复查询减少来源访问，但这些观察不建立生产延迟、容量或可用性结论。

保留应用和节点以供最终验证。独立训练环境可丢弃；在真实 AWS 账户中，应移除不需要的缓存以停止持续资源费用。

总结

你创建了单节点 Valkey 缓存，连接了提供的商品应用，并观察 cache-aside 的未命中和命中。缓存 JSON 与 DynamoDB 权威商品一致，重复命中避免了再次回源。接下来探索来源更新后如何用 TTL 和显式失效保持响应新鲜。

进一步阅读 AWS 官方资料：Cache-aside 数据流; 选择缓存连接端点。