键的时间预算
Redis TTL 生命周期规划器
TTL 不是一个随手填上的数字。它决定数据驻留多久，也决定内存会以怎样的节奏归还。
到期分布
内存回收时间窗
柱形越集中，Redis 在同一段时间内需要处理的到期键越多。
最早到期27 分钟
最晚到期33 分钟
回收波宽6 分钟
峰值批次—
预计到期键数240 个键 / 14 个时间桶
27 分钟写入时刻之后33 分钟
节奏
当前抖动会把这批键摊到 6 分钟的窗口内，内存不会在单一秒点集中归还。
生命周期标签
写入并计时SET key value EX 1800
驻留窗口键可读，剩余时间逐秒减少
到期与回收逻辑上已过期；访问检查或主动过期周期完成清理
返回值判读
TTL 的三个信号
这里的负数不是“还剩负几秒”，而是键状态的专用编码。
TTL session:user:42 → (integer) 94
键存在，而且剩余 94 秒。它会继续占用内存，倒计时归零后进入到期清理范围。
记忆边界：-1 是“存在但没有倒计时”，-2 是“已经找不到这个键”。两者的后续动作完全不同。
TTL = -1
永不过期 key 审计清单
永不过期不等于错误，但它必须有所有者、保留理由和明确的回收出口。
当前有 3 项需要补齐
- 为这类键设置可观测的数量或内存上限。
- 补上业务实体消失或版本退出时的删除路径。
- 约定下一次复审日期。
TTL 到点后，内存是否在同一毫秒立即归还？
逻辑过期先发生一旦截止时间过去，键就不应再作为有效数据返回。
清理依赖两条路径访问键时会检查过期；Redis 也会周期性抽样处理已经到期的键。
分布决定回收节奏给大量键增加合理抖动，能把到期检查和空间释放摊到更宽的时间窗。