缓存故障时保持应用可用

简介

可选缓存停止响应时，商品查询仍应可用。先观察应用当前的失败，设置有界缓存超时和来源回退，然后恢复缓存并验证命中恢复。

先完成“为商品查询添加缓存”。当前新环境提供独立应用、DynamoDB 来源和已连接的 Valkey 节点。使用 Terminal 执行命令，通过 AWS View 观察实际状态及商品响应。提供的故障控件仅暂停本实验缓存进程，无需自行开发故障注入工具。

认证考点

观察真实缓存超时

本步骤先建立健康行为，再观察缓存停止响应时的情况。超时限制应用等待响应的时长。暂停进程仍有连接端点，但无法响应请求；这与缓存未命中不同。

确认身份和配置：

cd /home/labex/project
aws sts \
  get-caller-identity
cat app.json

ARN 以 labex-ca03-operator 结尾。准备好的应用设置为 timeout_seconds: 2 和 fallback_on_error: false。缓存健康时，请求商品 101 两次：

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

首次请求读取来源，第二次使用缓存。启动提供的故障：

curl -sS -X POST \
  -H 'Content-Type: application/json' \
  --data '{"action":"pause"}' \
  http://127.0.0.1:8080/api/fault

再次请求商品，同时显示 HTTP 状态：

curl -sS -w '\nHTTP %{http_code}\n' \
  http://127.0.0.1:8080/api/products/101

这是预期失败。约两秒后，应用返回 HTTP 503 和 failure: TimeoutError；数据库仍可能保存该商品。缓存不可用不应自动演变为商品目录不可用。

限制等待并回退到来源

本步骤让应用在可选缓存出错时读取 DynamoDB。回退是缓存错误后的有意替代路径；普通未命中只是不存在缓存值。

在此受控训练情境中使用 0.2 秒超时，并启用回源：

jq '.timeout_seconds = 0.2 | .fallback_on_error = true' \
  app.json > app.next.json
mv app.next.json app.json

保持缓存暂停，再请求同一商品并显示请求耗时：

curl -sS -w '\nHTTP %{http_code}; elapsed %{time_total}s\n' \
  http://127.0.0.1:8080/api/products/101

响应为 HTTP 200，包含当前来源价格 20.00、served_from: source 和 cache_error: TimeoutError。受控缓存等待现在约为 0.2 秒。故障期间每个请求都新增来源读取，因此回源保护功能，却增加数据库负载。

在 AWS View 比较更新后的超时、暂停故障状态和来源读取次数。单环境计时练习不证明生产超时、负载容量或 AWS 可用性保证。

恢复缓存并再次观察命中

本步骤解除受控故障，验证应用重新使用缓存。健康缓存行为与成功回源是不同结果。

恢复提供的缓存进程：

curl -sS -X POST \
  -H 'Content-Type: application/json' \
  --data '{"action":"resume"}' \
  http://127.0.0.1:8080/api/fault

请求商品 101 两次：

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

观察 served_from: cache 和 cache_error: null。若原 TTL 在排查中到期，首次请求可能从来源重新填充键，下一次则命中。连续命中时来源读取次数不再增加。

保留已恢复的缓存及有界回源配置以供验证。真实服务应同时监控缓存错误及故障期间增加的来源流量；回源不能让不可用的源数据库恢复工作。

总结

你观察了真实暂停缓存的超时，启用有界回源，并在恢复后重新获得缓存命中。未命中和缓存错误需要不同处理；回源维持来源支持的响应，但在故障期间增加数据库工作。

进一步阅读 AWS 官方资料：根据工作负载选择客户端超时。