3. TTL 与过期策略

TTL（Time To Live）是缓存系统中控制数据有效期的核心机制。设置不当会导致缓存击穿、雪崩或内存浪费；扫描机制与时间精度则决定了系统在高并发下的行为一致性。本章围绕 TTL 设置原则、过期扫描机制、时间精度影响三个维度展开，明确系统边界与分层职责。

3.1 TTL 设置原则

TTL 的赋值不应是随意数字，而应综合业务容忍度、数据更新频率、系统负载三个维度进行决策。以下是经过验证的六条原则：

1. 业务差异化原则：热点数据可设置较长 TTL（如用户会话 30 min），冷数据或不常变数据可设置 1 h 以上。
2. 分钟级粒度原则：避免使用秒级 TTL 引发频繁过期扫描，推荐以分钟为基本单位，如 5 min、30 min。
3. 阶梯衰减原则：对同一类数据按访问热度分层，热度越高 TTL 越长，热度降低后逐步缩短。
4. 抖动消除原则：在基础 TTL 上叠加 ±10% 随机偏移，防止大量 key 同时过期造成缓存雪崩。
5. 失效前预热原则：对于聚合计算结果，TTL 设置应预留 2–3 个后台刷新周期，确保重建时间窗口内不返回旧数据。
6. 资源水位原则：内存占用超过 70% 时，应主动调低非关键数据的 TTL，优先保留高频热点。

3.2 过期扫描机制

常见的过期扫描策略分为三类，不同系统可能有混合实现。下表对比了三种机制的核心差异：

3.3 时间精度对系统影响

TTL 依赖系统时钟，时间精度问题会引发以下三类异常：

• 时钟漂移：分布式节点间时钟不同步，导致同一 key 在不同节点上的剩余 TTL 不一致，引发读写路由错乱。
• 粒度浪涌：秒级 TTL 在整秒时钟边界集中触发过期，产生“时间戳毛刺”，瞬间压力峰值可达均值的 5–8 倍。
• 精度取舍：毫秒级 TTL 可满足金融领域精确控制，但需要高精度时钟服务（如 PTP），普通业务采用秒级即可。

3.4 策略选型决策树

下方 SVG 图展示了从业务场景到最终配置的推导路径，帮助架构师在系统设计阶段快速定位合适的 TTL 与扫描策略组合。

3.5 落地步骤与验收标准

1. 步骤一：业务归类——将缓存数据按访问热力图分为 hot / warm / cold 三类，为每类设置基准 TTL。
2. 步骤二：抖动配置——在配置中心添加随机偏移参数，例如 ttl.jitter.percent=10。
3. 步骤三：扫描引擎选型——若使用 Redis，启用 activerehashing yes 与 hz 10；若用本地缓存，实现一个独立 Timer 线程，扫描间隔为 TTL 平均值的 1/10。
4. 步骤四：时钟同步——所有缓存节点部署 NTP 并开启 PTP（精度需求 ≤50 ms 时）。
5. 步骤五：压测验证

# 模拟 5000 key 并发写入，TTL 随机分布在 300~900s
wrk -t12 -c400 -d60s --latency http://127.0.0.1:6379/cache/set?ttl=random-600
# 观察过期 key 分布是否均匀（预期：每 10s 过期 key 数 ≤ 200）
redis-cli info keyspace | grep expires