使用 TTL 使临时记录过期

介绍

临时会话记录到期后，即使存储清理尚未完成，也应停止向用户提供。你将启用 TTL，修复类型错误的过期属性，并配置提供的应用，使它在实际读取服务数据时排除过期记录。

请先完成“为订单创建 DynamoDB 表”和“使用分区键和排序键查询订单”。全新环境提供一张独立的会话表、三条合成记录和一个读取器框架，供你配置 TTL 和读取过滤条件。使用 /home/labex/project、官方 AWS CLI 和 AWS View。本实验评估 TTL 配置和识别过期数据的读取行为，不承诺 AWS 后台删除的完成期限。

认证考点

实验概览

在准备好的会话表上启用过期功能

本步骤中，你将配置表的过期属性。生存时间（Time to Live，TTL）让 DynamoDB 最终移除过期项目。它是异步清理机制，并非在每个项目到期的那一秒精确删除它的计时器。在服务尚未完成删除时，应用仍必须拒绝返回过期数据。

对本实验的会话读取器，记录是否可提供给应用与是否已从存储删除是两个结果。你将检查 TTL 状态、修复有效期类型，再对比应用结果与原始读取。ENABLED 证明配置；应用排除过期会话证明读取策略，并不证明服务已删除项目。

全新环境中的会话表包含有效、过期和永久的合成记录。启用任何功能之前，先检查记录的类型以及处于禁用状态的 TTL 配置。

cd /home/labex/project

aws dynamodb scan --table-name labex-d05-sessions --consistent-read

aws dynamodb describe-time-to-live --table-name labex-d05-sessions

在 expires_at 上启用 TTL。每个项目提供自己的到期时间；表配置决定 TTL 服务检查哪个属性。缺少该属性表示这个项目没有 TTL 到期时间。

aws dynamodb update-time-to-live \
  --table-name labex-d05-sessions \
  --time-to-live-specification Enabled=true,AttributeName=expires_at

aws dynamodb describe-time-to-live --table-name labex-d05-sessions

描述结果显示 ENABLED 和 expires_at 后再继续。在 AWS 上，启用可能需要一段时间；处于 ENABLING 状态时，应重复执行描述命令，而不是反复更改配置。查看上方的 AWS View，展开会话卡片中的 TTL 条目。

修复过期记录的属性类型

本步骤中，你将存储有效的到期值。DynamoDB TTL 要求 Number 类型的 Unix 纪元秒数，也就是自 1970-01-01 UTC 起经过的秒数。使用毫秒会表示遥远的未来时间。看起来像时间戳的字符串仍然是 String 类型，TTL 进程会忽略它。

通过精确的键检查预置的过期记录。它的 expires_at 被故意编码为 S；启用 TTL 并不会修复这个类型。

aws dynamodb get-item \
  --table-name labex-d05-sessions \
  --key '{"session_id":{"S":"expired"}}' \
  --consistent-read

使用 Linux 的 date 命令计算一小时前的到期时间。+%s 输出 Unix 秒数，$(...) 将该输出保存到 EXPIRED 中。每次运行的值都不同，但它必须早于当前时间。

EXPIRED=$(date -u -d '1 hour ago' +%s)
echo "$EXPIRED"

将带类型的值写入一个小型 JSON 文件。这里的 heredoc 使用不带引号的 JSON 分隔符，因此 shell 会将 $EXPIRED 替换为你的时间戳；此前带引号的分隔符会保留原始文本。把 JSON 放入文件可以避免转义其中的引号。

cat > expiry-values.json <<JSON
{":expires":{"N":"$EXPIRED"}}
JSON

使用 UpdateItem 仅替换过期属性。file:// 加载值文件；存在条件可以避免在异步删除已经移除记录时重新创建它。

aws dynamodb update-item \
  --table-name labex-d05-sessions \
  --key '{"session_id":{"S":"expired"}}' \
  --update-expression 'SET expires_at = :expires' \
  --condition-expression 'attribute_exists(session_id)' \
  --expression-attribute-values file://expiry-values.json \
  --return-values ALL_NEW

返回的过期项目具有 expires_at: {"N": "..."}，其时间位于过去，且 purpose 保持不变。有效项目的到期时间仍在未来；永久项目仍然没有到期属性。在 AWS 上，如果记录在后续读取或更新前已被移除，只有成功的服务响应才能证明它已删除，连接失败不能作为证据。

在应用读取流程中排除过期数据

本步骤中，你将在 TTL 清理尚未完成时保护读取行为。提供的 session-reader 应用读取普通的 session-reader.json 设置，并实际发送 Scan 请求。它的默认配置故意也返回过期数据。你可以查看应用源代码，但无需编写 Python。

./session-reader

在这个环境中，未过滤的读取器仍会返回全部三条记录，包括 expired。这不能证明 TTL 配置错误。AWS 后台删除可能稍后发生，本实验的验收不包含精确的删除时间安排。

启用应用的过期过滤功能。带引号的 heredoc 按原样写入 JSON，替换设置文件。

cat > session-reader.json <<'JSON'
{
  "table": "labex-d05-sessions",
  "filter_expired": true
}
JSON

./session-reader

应用使用 attribute_not_exists(expires_at) OR expires_at > :now，传入 Number 类型的当前秒数，并沿着 Scan 的续读键读取后续页面。现在它只返回 active 和 permanent，Count 为 2，FilterExpired 为 true。永久记录被有意保留，因为它没有过期策略。过滤可以防止应用提供过期数据，但不会减少已经执行的扫描读取工作。

比较按键直接读取的原始结果与应用结果。

aws dynamodb get-item \
  --table-name labex-d05-sessions \
  --key '{"session_id":{"S":"expired"}}' \
  --consistent-read

直接读取的结果可能仍包含 expired，而应用会排除它。如果 AWS 已经删除它，成功但没有项目的 GetItem 响应也符合 TTL 的行为。AWS View 显示 TTL 配置和读取器实际返回的两个项目，不会把过滤描述为对存储记录的物理删除。

删除本实验的会话表

本步骤中，你将在验证过期配置和应用行为后，明确执行表清理。不要等待 TTL 删除整张表：TTL 删除项目，不会删除表本身。删除这张临时表也会移除它的 TTL 配置。

aws dynamodb delete-table --table-name labex-d05-sessions

aws dynamodb wait table-not-exists --table-name labex-d05-sessions

aws dynamodb list-tables

aws dynamodb get-item \
  --table-name labex-d05-reference \
  --key '{"id":{"S":"platform"}}' \
  --consistent-read

只剩下参考表，其中的 note 为 keep unchanged。成功的表清单查询和参考记录读取，证明删除后连接仍正常。AWS View 会移除会话表和读取器结果。临时连接随本 VM 结束。

总结

你在 expires_at 上启用了 TTL，将字符串时间戳替换为数字形式的纪元秒数，并在实际应用的读取流程中排除了过期会话。你区分了逻辑过期与异步物理删除，并有意保留了永久记录。最后，你删除了本实验的表，并保留了无关的参考表。

进一步阅读 AWS 官方资料：TTL 过期与异步项目删除。